Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Ralf Corsepius]

On Tue, 2006-11-21 at 20:40 -0800, Till Straumann wrote:
> Ralf Corsepius wrote:
> > On Tue, 2006-11-21 at 15:50 -0800, Till Straumann wrote:
> >   
> >> FYI
> >>
> >> linux (2.6.18) is built with -fno-strict-aliasing
> >>     
> > Well, the Linux kernel has long record of clashing with GCC, rsp. GCC
> > having broken  "unclear spots" inside of Linux.
> >
> >   
> >>  and I believe that's what we
> >> should do. It is extremely hard to find all problematic cases of aliasing
> >> and as someone pointed out, as gcc gets smarter we'll run into more
> >> problems.
> >>     
> > We can't avoid having to identify and fixing all those spots and
> > therefore MUST NOT use -fno-strict-aliasing. In fact, a long series of
> > changes having gone into rtems > 4.6 actually originates from this
> > background.
> >   
> All I can say is that 'apparent fixes' like intermediate (void*)
> casting or intermediate variables don't fix this (but make
> the compiler warnings go away).
True, blindly applying casts doesn't fix it. You'll have to look into
the code.

But, as you clearly showed, blindly applying the "union approach",
doesn't fix this either.

That's one reason, why I am asking people to report spots in RTEMS where
they see this showing effect.

The correct approach would be to write clean code and to avoid casts
whenever possible. In particular, to avoid constructs like 
type* x = (type*) &var;

Ralf