Fwd: Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

Joel Sherrill joel.sherrill at oarcorp.com
Tue Nov 21 16:47:03 UTC 2006


Peer Stritzinger wrote:
> Joel,
>
> On 11/21/06, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>   
>> I am more concerned about the _Chain_Head and _Chain_Tail routines.
>> I don't see how to clean them up without the union.  And I believe (but
>> can't prove) that they are the root of gcc's confusion.
>>     
>
>   
>> >From what I learned during the hunt this might very well be.
>>     
>
> Nevertheless the question is if the complete code behaves correctly with
> strict-aliasing.  I mean if you are strict about strict-aliasing you
> may have no overlapping structs at all not depending if you use tricks
> to tell gcc what to do (or confuse the optimizer so it will work ...
> until it gets a bit smarter in the next release).
>
>   
I don't think there are any other truly overlapping structures in RTEMS 
proper.
There are only cases where something is "inherited" like Thread_Control
starts with Object_Control which in turn starts with Chain_Node. 

> But overlapping structs are used all over the code as it is very often
> especially in operating system code.  Thats actually the reason for
> the existence of
> -fno-strict-aliasing.  Its telling the compiler that you intend to
> overlap structs and do some punning now and then.  Looks like a
> (manual) space against time optimization(supposing the code will run
> faster when we assume strict-aliasing).
>   
GCC has to be able to honor unions so I don't see why that representing the
structure correctly is the way to go.
> The -Wstrict-aliasing warnings (included in -Wall) do not report all cases
> that might break the strict-aliasing rule.
>
> You might work with -Wstrict-aliasing=2 additionally while trying to
> root out more
> cases.  BTW they both probably only work when -On n > 2 is also on.
>
>   
OK.
> None of these warning switches claim to get all strict-aliasing violations.
>
> Regards,
> -- Peer
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   




More information about the users mailing list