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

[jameskuyper at verizon dot net]

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

--- Comment #31 from James Kuyper Jr. <jameskuyper at verizon dot net> ---
(In reply to rguenther@suse.de from comment #29)
> On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:
...
> > The relevant wording is "anywhere that a declaration of the completed type of
> > the union is visible.", so it's unambiguously the type, not the object, which
> > must be visible. A declaration of the completed type can be visible without any
> > objects of that type being visible, and that's sufficient for this rule to
> > apply.
> > 
> > > ...  Must the access be performed
> > > using the union object, or just the union type, or neither?
> > 
> > It says only that "it is permitted to inspect the common initial part"; it
> > imposes no restrictions on how the inspection may be performed. Clearly,
> > inspection through an lvalue of the union's type must be permitted, but it is
> > also permitted to use the more indirect methods which are the subject of this
> > bug report, simply because the standard says nothing to restrict the permission
> > it grants to the more direct cases.
> 
> Note I repeatedly said this part of the standard is just stupid.

As a judgement call, I reserve the right to disagree with you on that point,
particularly if that judgement was based primarily on the following
misconception:

> ...  It makes
> most if not all type-based alias analysis useless.

How could that be true? It only applies to pairs of struct types that are the
types of members of the same union, it only applies within the scope of a
completed definition of that union's type, and it doesn't apply if the
implementation can prove to itself that the two objects in question are not
actually members of the same union object. It seems to me that the need to take
this rule into consideration would come up pretty infrequently.

Code which relies upon this feature to implement a C-style approximation to
inheritance has been fairly common, which is precisely why the C committee
decided to create this rule, to make sure such code had well-defined behavior.

> Which means I'll refuse any patches implementing it in a way that affects
> default behavior.  A clean patch (I really can't think of any clean 
> approach besides forcing -fno-strict-aliasing!) with some extra flag
> (well, just use -fno-strict-aliasing ...) would be fine with me.

I can understanding not making this the default behavior if you feel that way;
I only use gcc in fully standard-conforming mode, anyway, so that doesn't
matter to me. However, personally, I would prefer it if gcc's fully-conforming
mode took full advantage of all the optimization opportunities legitimately
enabled by 6.5p7 (which does not include opportunities revoked by 6.5.2.3p6).