Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Joel Sherrill]

Thomas Doerfler wrote:
> Joel,
>
>
> Joel Sherrill schrieb:
>
> ... lot of conversation snipped away....
>
>   
>>> - In parallel, 4.7 will be cut with -fno-strict-aliasing
>>>
>>> - the 4.8 development branch will temporarily use -fno-strict-aliasing
>>> aswell, until the code has been revised
>>>   
>>>       
>> I don't know how Ralf is going to add this compiler flag.  It might go 
>> in as global
>> or not.  If it gets added individually in Makefile.am's then it will be 
>> possible to
>> slowly take it out.  If it is in a single place, it is either in or out.
>>     
>
> Hm, I don't think it is a good idea. Assume we have cleaned the
> networking code, but the RTEMS chain code is not yet aliasing-clean.
> When a networking function would include the chaining, it would break if
> we reenable -fstrict-asliasing for networking.
>
>   
I don't think turning it on/off in a single Makefile is practical and 
agree with the
potential scenario.  What I would really like to do is:

+ no-strict-aliasing on 4.7
+ if your chain modifications fix the problem, let's review them
and apply them to CVS/4.8 immediately.
+ leave strict-aliasing on for 4.8 as the default.  We need the testing.
+ take Ralf's list and work it from "low to high" where low is
places like the SuperCore that trickle up and out.  It is possible that
fixing the chain fixes other places so it is important to regenerate the
candidate list after each fix.

I'm really concerned that if strict-aliasing is off by default in CVS,
then we will never turn it back on.  A configuration switch which
defaults differently is OK to me -- especially since I can see compiling
a lot with it on and off and generating lists. :-)

--joel

> wkr,
> Thomas.
>
>
>