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

[rguenther at suse dot de]

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

--- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> 
> James Kuyper Jr. <jameskuyper at verizon dot net> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jameskuyper at verizon dot net
> 
> --- Comment #28 from James Kuyper Jr. <jameskuyper at verizon dot net> ---
> (In reply to Martin Sebor from comment #17)
> > The C Union Visibility rule was intended to cover that case.  The trouble is
> > that the rule tends to be interpreted differently by different people, users
> > and implementers alike: Is it the union object that must be visible at the
> > point of the access, or just the union type?
> 
> 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.  It makes
most if not all type-based alias analysis useless.

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.