Fwd: Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 184.108.40.206
joel.sherrill at oarcorp.com
Tue Nov 21 16:47:03 UTC 2006
Peer Stritzinger wrote:
> 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
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.
> None of these warning switches claim to get all strict-aliasing violations.
> -- Peer
> rtems-users mailing list
> rtems-users at rtems.com
More information about the users