Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[gregory.menke at gsfc.nasa.gov]

Thomas Doerfler writes:
 > Ralf,
 > 
 > 1.) In the previous discussion we have at least hit some spots where
 > people started to think, whether the various RTEMS code packages comply
 > with the strict aliasing requirements.
 > 
 > 2.) Peer Stritzinger has started this discussion with his posting, that
 > RTEMS chain code breaks in rare (but legal) cases, when GCC4 is used
 > with its heavy (and valuable) optimizations.
 > 
 > IMHO we have four possible ways to deal with this:
 > 
 > 1.) We simply ignore the bug report, book the occurrences in Peer's
 > system to a variant of the Pauli Effect and keep things going as they are.
 > 
 > 2.) We set "-fno-strict-aliasing" now and forever
 > 
 > 3.) we use "-fno-strict-aliasing" for RTEMS 4.7 and, ASAP we build a
 > strategy on how to get ALL code aliasing clean.
 > 
 > 4.) We stop cutting 4.7, and build a strategy right now on how to get
 > the code aliasing clean.
 > 
 > I personally would tend to 3). The disadvantage is, that we loose some
 > performance boost (which we did not have with GCC3), but we will not
 > delay 4.7 for half a year.
 > 

Strictly as a user, I would rather have RTEMS slower and stable.  On one
hand I appreciate RTEMS keeping up with the toolchains, but OTOH
sometimes its a little too close to the bleeding edge for comfort.
Weird and rare errors that destablilize the OS are a nightmare scenario
wheras the cost of slightly lower performance is lots easier to deal
with.

When people start talking about compiler optimizations causing the OS to
fail under obscure and difficult to debug circumstances, it means to me
the toolchain and OS source are not well mated and its time to pause and
get the engineering right.

Regards,

Greg