Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Chris Johns]

Ralf Corsepius wrote:
> On Wed, 2006-11-29 at 10:05 -0600, Joel Sherrill wrote:
>> The core of RTEMS code was started 10 years before C99 was approved. 
>> Was strict aliasing as an valid optimization even addressed before C99?
> I don't know, but ... I've strict-aliasing had been active in GCC at
> least since gcc-3.4 (!).

It looks to me like the issue has been around since C89, but I have not 
directly checked any of the standards. If you take a look at this document:

  http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

a C99 rational, on page 59, line 35 you can see a reference to the C89 
standard. To quote this document (and save everyone downloading):

  In practice, aliasing arises with the use of pointers. A contrived
  example to illustrate the issues is

    int a;
    void f(int * b)
    {
      a = 1;
      *b = 2;
      g(a);
    }

  It is tempting to generate the call to g as if the source
  expression were g(1), but b might point to a, so this optimization
  is not safe. On the other hand, consider

    int a;
    void f( double * b )
    {
      a = 1;
      *b = 2.0;
      g(a);
    }

  Again the optimization is incorrect only if b points to a. However,
  this would only have come about if the address of a were somewhere
  cast to double*. The C89 Committee has decided that such dubious
  possibilities need not be allowed for.

  In principle, then, aliasing only need be allowed for when the
  lvalues all have the same type. In practice, the C89 Committee
  recognized certain prevalent exceptions:

   • The lvalue types may differ in signedness. In the common
     range, a signed integer type and its unsigned variant have
     the same representation; and it was felt that an appreciable
     body of existing code is not “strictly typed” in this area.

   • Character pointer types are often used in the bytewise
     manipulation of objects; a byte stored through such a
     character pointer may well end up in an object of any type.

   • A qualified version of the object’s type, though formally a
     different type, provides the same interpretation of the value
     of the object.

Section 6.5.4 on page 66 is worth a read. I also found the new C99 
restrict keyword in section 6.7.3.1 and it looks interesting.

Regards
Chris