Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Joel Sherrill]

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

FWIW if I remember correctly from my runs a couple of weeks ago, tmtest 
times
for semaphores and internal operations (tm26/tm27) are nearly identical 
for sparc/erc32
for the end of the 4.6 branch and the current spot on the 4.7 branch 
using the tools
provided as RPMs.    So that's gcc 3.2.3 versus 4.1.1. 

I would guess that networking throughput would be another good measure.  
Fundamentally
it is built on semaphores and events for synchronization plus lots of 
TCP/IP code.  If something
got better, 4.7 would be measurably faster on the same hardware.

--joel
>
>