|
From: Christoph P. <chr...@gm...> - 2002-03-01 18:58:45
|
As I mentioned in another mail, we write and work on a safety critical OS. For this we also must validate the compilers (assessment), and we know from our experiments and analysis, that we MUST use the option `-fno-strict-aliasing' (we must not deliver software without this option). We also found strange constructions using optimizing. Further I heard, that the GCC team also discuss, if `-fno-strict-aliasing' should become the default, but I do not know more about this discussion. Bye Christoph P. "Eric W. Biederman" wrote: > > Jean-Jacques Michel <jjm...@li...> writes: > > > Ken Yap a écrit : > > > > > > >In "rtl_transmit", the variable nstype is updated only AFTER > > > >the memcpy is done ! > > > >Moving the "nstype = htons(type)" far from the "memcpy" makes > > > >the problem disappear. > > > > > > Ok, will patch, many thanks. Will you submit a gcc3 bug report? > > > > I don't really know if you can consider this as a GCC bug : > > > > If you work with a "char *ptr", > > there is nothing the compiler can know about *ptr when you use ptr > > as a parameter of a function.From my point of view, you cannot blame > > the compiler for this. > > Exactly there is nothing the compiler can know so it must > be conservative. The compiler can only take this kind of > action if the types are definenitely different, so they cannot alias. > I haven't explicitly heard about void * but I know it must assume > char * pointers can alias with any type. > > It might be worth trying with: -fno-strict-aliasing and see > if the problem persists. > > Eric > > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers -- ------------------------------------------------------- private: chr...@gm... company: chr...@al... |
