Fwd: Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Peer Stritzinger]

Joel,

On 11/21/06, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> I don't think there are any other truly overlapping structures in RTEMS
> proper.
> There are only cases where something is "inherited" like Thread_Control
> starts with Object_Control which in turn starts with Chain_Node.

Maybe I'm getting paranoid but I'm no longer sure if in principle this
kind of inheriting
might not also break under heavy optimization someday.  As long as GCC
passes pointers between
functions in different modules this might well work but as more and
more code gets inlined and optimizations get more global more trouble
might occur.

Just as a thought experiment: what if gcc would collect all the sourcecode of
the whole system and do true global optimization under strict-aliasing
over everything.
Would the code then be correct?

> GCC has to be able to honor unions so I don't see why that representing the
> structure correctly is the way to go.

To spare everybody the lookup.  Here is what gcc-4.1.0 manuals says about this
for reference:

`-fstrict-aliasing'
     Allows the compiler to assume the strictest aliasing rules
     applicable to the language being compiled.  For C (and C++), this
     activates optimizations based on the type of expressions.  In
     particular, an object of one type is assumed never to reside at
     the same address as an object of a different type, unless the
     types are almost the same.  For example, an `unsigned int' can
     alias an `int', but not a `void*' or a `double'.  A character type
     may alias any other type.

     Pay special attention to code like this:
          union a_union {
            int i;
            double d;
          };

          int f() {
            a_union t;
            t.d = 3.0;
            return t.i;
          }
     The practice of reading from a different union member than the one
     most recently written to (called "type-punning") is common.  Even
     with `-fstrict-aliasing', type-punning is allowed, provided the
     memory is accessed through the union type.  So, the code above
     will work as expected.  However, this code might not:
          int f() {
            a_union t;
            int* ip;
            t.d = 3.0;
            ip = &t.i;
            return *ip;
          }

     Every language that wishes to perform language-specific alias
     analysis should define a function that computes, given an `tree'
     node, an alias set for the node.  Nodes in different alias sets
     are not allowed to alias.  For an example, see the C front-end
     function `c_get_alias_set'.

     Enabled at levels `-O2', `-O3', `-Os'.