Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 184.108.40.206
peerst at gmail.com
Mon Dec 4 08:40:40 CST 2006
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 -
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
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
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?
More information about the rtems-users