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

[aph at gcc dot gnu.org]

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

--- Comment #62 from Andrew Haley <aph at gcc dot gnu.org> ---
Just a bit of clarification:

(In reply to James Kuyper Jr. from comment #59)
> 
> > 1) all type-based alias analysis is effectively impossible
> 
> Alias analysis is only affected by the special guarantee if
> a) the types involved are both struct types

> b) both struct types are members of the same union
> c) the struct types share a common initial sequence

OK to all of those.

> d) the code in question inspects the value of one of the members of the
> common initial sequence.

While this is a reasonable inference from what the text of the
standard says, type-based alias analysis, by definition, does not pay
any attention to what any piece of code does.  The analysis is purely
type-based: that is to say, it only uses the types, and the only
question it answers is "Do these types alias?"

> e) a completed declaration of the union type that they are members
> of is visible at the point in the code where the inspection occurrs.

As explained elsewhere, TBAA doesn't use visibility as a criterion.

> It seems to me that the overwhelming majority of cases will fail to
> meet at least one of those requirements, so type-based alias
> analysis is still possible, it's just made more complicated by the
> need to check for those things.

That's not quite right, as explained above.  If you use information
other than types in alias analysis, it's no longer TBAA.  It is a
fundamental principle of TBAA that the result of an aliasing query
never changes for any pair of types.

We are extremely unlikely to redesign a big part of the optimizer for
this dusty corner case.