Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Till Straumann]

I vote for 2.

Even if we get the code totally alias clean
one day we'd have to go through this subtle cleanup
procedure again every time something new (a driver, a port, ...)
is contributed. Given that the benefits are (I suspect)
undetectable but subtle problems may be triggered under
rare circumstances I really can't see any advantage
this optimization gives us [OK, some benchmarking
should be done].

-- Till

Eric Norum wrote:
>> 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.
>
>
>