Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Joel Sherrill]

Eric Norum wrote:
> In the interests of not delaying 4.7 for another year I suggest that  
> we simply add -fno-strict-aliasing to all gcc invocations.  I don't  
> see anything wrong with this approach in the near term.  As has been  
> pointed out by others, many other kernel development projects have  
> resorted to this technique.
>
> I know that Ralf is opposed to this, but I have not heard a reason to  
> convince me.
>   
I thought about this over the holiday weekend and
a few thoughts kept coming back. 

+ it is an optimization that even the example in
the gcc manual shows code which might not work.
Notice they don't say will not -- just "might not."
Anything short of pure union -- no pointers to objects
in unions is subject to breakage per the manual.

+ I don't know how common code is in RTEMS that will break
under this optimization.  I can see where potentially
any communications or device driver code is in question.

+ It is an OPTIMIZATION and an optional one at that.
This isn't a test of manhood.  There isn't any shame in
disabling it. 

+ I don't know how much benefit turning it on would have
anyway.  In general, RTEMS proper is written to avoid unnecessary
memory references so this would probably not have big impact.
So how much performance gain could turning this on win anyway?

+ As Eric points out, other OSes with larger user and maintainer
bases have not found a solution to using this optimization
safely.  There is a lot of code in RTEMS from BSD.

+ More importantly, we are trying to get a release out.  The
most expedient solution is also the one with the least technical
impact on code stability.  I often get faulted for not pushing
for releases and this is one case where I see no end to the amount
of work in question to address every place that is broken by
strict aliasing.

Bottom line is that if we want strict-aliasing on for 4.7, we
will be delaying the release.  This is a very bad thing.  I
am torn between Thomas' suggestions 2 and 3

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

Given Peer's report, for sure strict-aliasing causes a problem
on 4.7 and the most expedient and trustable solution is to disable it
for 4.7.

To determine if this is a branch only or forever thing, one piece
of data we need is the impact of this option on the tmtests. 
Assuming they all run on Peer's target hardware, we know
optimization is doing something there whether it is good or not. :)

--joel