[Bug c/65892] gcc fails to implement N685 aliasing of union members

["aph at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892

--- Comment #47 from Andrew Haley <aph at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Haley from comment #42)
> > 
> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their member types alias.  Alternatively,
> > a tighter implementation might restrict such declarations to a
> > compilation unit, in which case the alias oracle would scan only the
> > union types declared in that unit.
> 
> So for the middle-end the easiest thing would be if the FE would comply
> to its existing semantics and for the initial sequences generate a
> transparent struct.  Thus,
> 
> union {
>  struct A { int i; float f; double z; } a;
>  struct B { int i; float f; void *p; } b;
> };
> 
> would cause the FE to "implement" struct A and B like
> 
>  struct __init_seq1 { int i; float f; };
>  struct A { struct __init_seq1 _transp_memb1; double z; } a;
>  struct B { struct __init_seq1 _transp_memb2; void *p; } b;
> 
> then everything would work as expected from an aliasing point of view.
> The difficulty is probably that argument passing of A and B might
> change depending on how the ABIs are defined and how the backend handles
> those wrapping structs.

Nice.  I've got to admit that's a clever, idea, but it's also a very
big gotcha.

> But as you can clearly see the above would be also a way for the user
> to get what the clause permits without the clause being present.  So
> I'm not sure why this clause was added.

That's somewhat explained by N685, which does contain the rationale.
In short: proposal before N685 was to allow *every* pair of pointers
to structures with a common initial sequence to alias.  The revised
version (which was accepted) restricts this to structures with a
common initial sequence where a union of these structures is visible
to the compiler.

> language specifications have defects ...

Yabbut, N685 was accepted and the proposal does explain why.  Maybe it
shouldn't have been done that way, but it was done, and it was done
deliberately, as far as I can see.

> > > When I read the language text then a union declaration in between
> > > two accesses will change the semantic of the second?
> > 
> > Not necessarily.  It would be correct to collect all union
> > declarations at the end of parsing and then use those to feed the
> > alias oracle.  There's no actual need to restrict their scope.  Sure,
> > it would lead to GCC being somewhat over-cautious, but that's OK.
> 
> given the TBAA oracle is filled on-demand it is important that both
> outcomes are allowed. 

Okay, I don't get this.  Why not simply say that if a union type with
the initial common sequence exists anywhere, it is as though it were
declared at the start of every TU.

> I still don't see how we can make it work easily in the middle-end.

I don't think I ever said it would be easy!  I am saying, though, that
it's not the end of TBAA as we know it, but a refinement in which a
front end can feed into the alias oracle sets of types that are known
to alias.

You can think of it as a declaration:

    __alias__ {
      type_a, type_b, type_c
    };

which is an additional input to the oracle.