Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Till Straumann]

Peer Stritzinger wrote:
> 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.
>   
While the optimization is optional, programs that violate the
aliasing rule are unfortunately not C99 compliant - the
standard does *not* declare this rule optional, unfortunately.

-- Till
> 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?
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>