Re: Tricky(?) aliasing question.

[Andrew Haley <aph at redhat dot com>]

Sergei Organov writes:

 > If we come back to strict aliasing rules, then I will have to refer once
 > again to already cited place in the standard that says that I'm
 > permitted to access an object not only through a compatible type, but
 > also through a structure containing a field of compatible type (and
 > there is no indication that those field should be the first one in the
 > structure):
 > 
 >    An object shall have its stored value accessed only by an lvalue
 >    expression that has one of the following types:
 >  
 >       - a type compatible with the effective type of the object,
 >       [...]
 >       - an aggregate or union type that includes one of the aforementioned
 >         types among its members (including, recursively, a member of a
 >         subaggregate or contained union)
 > 
 > Or are you saying that I don't violate strict aliasing rules, but
 > instead some other rule from the standard? If so, then how to explain
 > that GCC stops to "miscompile" the code when I add -fno-strict-aliasing
 > option?

That's what it's for.  -fno-strict-aliasing exists to support such
broken code.  

 > Not that I insist on sane results of compilation of broken code,
 > but it seems that GCC thinks it's violation of strict aliasing
 > rules.

6.3.2.3 makes it quite clear that this:

   H0 h0 = *(H0*)&f;

produces undefined behaviour.

Andrew.