Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Peer Stritzinger]

On 12/5/06, Kim Barrett <kab at irobot.com> wrote:
> Some further web
> searches turned up the "may_alias" type attribute. I think that attribute
> would solve the rtems chain problem, without the nasty (and I think not
> actually portable in general) union approach.

That sounds for me a very intersting feature for a transition period.
If everything
that might still cause trouble is declared with __attribute__ ((may_alias))
strict-aliasing could be turned on again without having to rewrite the whole
code.

Then the data structures could be cleaned up one by one.

And this approach would also be save for inlined stuff in contrast to
a file by file specification in some Makefile machinery.

For ease of reference here the explanation out of gcc-4.1.0 manual:

`may_alias'
     Accesses to objects with types with this attribute are not
     subjected to type-based alias analysis, but are instead assumed to
     be able to alias any other type of objects, just like the `char'
     type.  See `-fstrict-aliasing' for more information on aliasing
     issues.

     Example of use:

          typedef short __attribute__((__may_alias__)) short_a;

          int
          main (void)
          {
            int a = 0x12345678;
            short_a *b = (short_a *) &a;

            b[1] = 0;

            if (a == 0x12345678)
              abort();

            exit(0);
          }

     If you replaced `short_a' with `short' in the variable
     declaration, the above program would abort when compiled with
     `-fstrict-aliasing', which is on by default at `-O2' or above in
     recent GCC versions.