Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Peer Stritzinger]

On 11/28/06, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

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

And as a optimization it is even a trade-off namely a possible space -
time tradeoff.
Code that breaks the strict-aliasing prerequsites is most times not
written accidentally so but to conserve program and data memory at the
expens of the compiler doing *possibly* more clever things with our
code.

Coding in a strict-aliasing compatible style usually means using
different data structures
and programming constructs that need more object code and/or more ram
and more levels of pointer indirection.

So it might be that overall performance of a changed RTEMS with strict-aliasing
might be even worse than what we get by -fno-strict-aliasing

> + 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?

When I looked at the PowerPC assembler code of the code that showed the problem
comparing the versions with and without -fno-strict-aliasing:

  * The no strict aliasing code does two memory accesses more

  * These were exactly the two accesses that were wrongly optimized away.

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

Actually from my involvement with the BSD crowd, they are not even trying to
avoid -fno-strict-aliasing since they probably are aware of the
optimization tradeoff.

If I look through the Ports Collection of FreeBSD -fno-strict-aliasing is set
for many programs ... as it looks like all the Perl stuff is built like this.

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

Can I help somehow running these tests?