Re: Tricky(?) aliasing question.

[Sergei Organov <osv at javad dot com>]

Andrew Haley <aph@redhat.com> writes:
> 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.

Could you please give direct answer to the following question:

Does the code in question violate strict aliasing rules?

>
>  > 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.

What it has to do with strict aliasing rules?

Anyway, the only undefined behavior in this section I've found is:

"7. A pointer to an object or incomplete type may be converted to a
    pointer to a different object or incomplete type. If the resulting
    pointer is not correctly aligned(57) for the pointed-to type, the
    behavior is undefined."

Let's suppose that in my example the alignment requirements for 'float'
and 'H0' types are the same. Then the cited item (7) allows me to
convert float* to/from H0* without invoking of undefined behavior.

Did I miss anything?

-- Sergei.