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

["jameskuyper at alumni dot caltech.edu" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #55 from James Kuyper Jr. <jameskuyper at alumni dot caltech.edu> ---
> ou need, at a minimum, to modify "accesses via" to
> "accesses directly via", in order to convey your intended meaning.
(In reply to Davin McCall from comment #54)
> (In reply to James Kuyper Jr. from comment #53)
> > [...] However, because those
> > pointers are passed to f(), which does dereference them, f() does accesses
> > those members, and it does so via the use of the '.' operator in the calling
> > routine. Therefore, you need, at a minimum, to modify "accesses via" to
> > "accesses directly via", in order to convey your intended meaning.
> 
> I thought it was clear that I was referring to access via the union. That is
> certainly what I did mean.

The problem is, you're using a statement that the access must occur via a
union, with the implication that the code in question does not access the
member through the union. The code in the original bug report does in fact
access the members through the union - indirectly, but through the union. It's
not possible to bypass the u.s1 step; the fact that u.s1 is the operand of an &
operator and the resulting pointer value is an argument to a function call, and
that the called function is the one that actually accesses the member through
that pointer, does not change the fact that the access came about as the result
of the use of the '.' operator on a union object. Therefore, if you want your
wording to convey your belief that such indirect use of the member selection
operator is excluded, your wording needs modification to make that clear. Of
course, if so modified, it would be saying something with no actual support in
the C standard.

> > I don't see anything in the standard's wording of 6.5.2.3p6 to justify
> > restricting what it says to direct accesses - it says "it is permitted to
> > inspect", without specifying restrictions on how the inspection may be
> > performed.
> 
> As I have said, it is in a section regarding access and in a paragraph
> discussing "use of unions". While I understand what you are saying, I don't
> feel my own interpretation is really that difficult to fathom, and I'm not
> the only one to take it. See http://archive.is/PnW28 (DR 257).

True, but keep in mind that the committee did not agree with his objections.
The example he was complaining about is still present in the current version of
the standard, without any changes that address the issues he raised (I happen
to agree with him that it would have been better to use a common initial
sequence with a length greater than one member, and to use a member other than
the first one for the example).

> > The words "anywhere that a declaration of the completed type of the union
> > is visible." would become pointless with your interpretation.
> 
> Yes, as I already said.

The standard explicitly says, referring to the same example mentioned in DR
257, that the second code fragment is not valid, but only "because the union
type is not visible within function f", implying that it would be valid if the
declaration of the union type were moved so that it would be visible inside
f(). If it were so moved, it would be essentially equivalent to the code which
was the original defect report. While examples are non-normative, that example
implies that the visibility clause was intended to actually serve a purpose
(and it seems obvious to me that it actually does so).