Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Eric Norum]

> 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.
>>

I vote for 2 or 3 -- in the short term they're the same.   I suspect  
that 2 is going to be the final answer, though.
I expect we're not really losing any performance doing this.  I don't  
recall anyone reporting a big speedup going from gcc-3 (which didn't  
have the strict aliasing rules) to gcc-4.


-- 
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793