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.
