Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in

Thomas Doerfler Thomas.Doerfler at
Tue Nov 28 16:17:31 UTC 2006


1.) In the previous discussion we have at least hit some spots where
people started to think, whether the various RTEMS code packages comply
with the strict aliasing requirements.

2.) Peer Stritzinger has started this discussion with his posting, that
RTEMS chain code breaks in rare (but legal) cases, when GCC4 is used
with its heavy (and valuable) optimizations.

IMHO we have four possible ways to deal with this:

1.) We simply ignore the bug report, book the occurrences in Peer's
system to a variant of the Pauli Effect and keep things going as they are.

2.) We set "-fno-strict-aliasing" now and forever

3.) we use "-fno-strict-aliasing" for RTEMS 4.7 and, ASAP we build a
strategy on how to get ALL code aliasing clean.

4.) We stop cutting 4.7, and build a strategy right now on how to get
the code aliasing clean.

I personally would tend to 3). The disadvantage is, that we loose some
performance boost (which we did not have with GCC3), but we will not
delay 4.7 for half a year.

Ralf, do you have a plan on how we can get the RTEMS packages aliasing


Ralf Corsepius schrieb:
> On Tue, 2006-11-28 at 09:12 -0600, Eric Norum wrote:
>> In the interests of not delaying 4.7 for another year I suggest that  
>> we simply add -fno-strict-aliasing to all gcc invocations.  I don't  
>> see anything wrong with this approach in the near term.  As has been  
>> pointed out by others, many other kernel development projects have  
>> resorted to this technique.
>> I know that Ralf is opposed to this, but I have not heard a reason to  
>> convince me.
> And I have not seen any bug in RTEMS having been fixed by
> -fno-strict-aliasing.
> However, I've seen a lot of people bogusly accusing strict-aliasing for
> code bugs, in general (Outside of RTEMS).
> Please folks, please provide cases, so we can go after this. So far this
> has not taken place, instead I've seen several "flare gun" approaches
> having been proposed.
> Ralf
> _______________________________________________
> rtems-users mailing list
> rtems-users at

embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at
PGP public key available on request

More information about the users mailing list