Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 18.104.22.168
chrisj at rtems.org
Wed Nov 29 23:15:51 UTC 2006
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:
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
void f(int * b)
a = 1;
*b = 2;
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
void f( double * b )
a = 1;
*b = 2.0;
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 22.214.171.124 and it looks interesting.
More information about the users