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

[txr at alumni dot caltech.edu]

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

--- Comment #21 from Tim Rentsch <txr at alumni dot caltech.edu> ---
[responding to comments from joseph@codesourcery.com in Comment 19]

>> Five:  The answer to the question is clearly No.  The example code
>> is very much on point to the "one special guarantee" clause, and
>> so the read access p1->m is permitted.  As the access is permitted,
>
> I maintain that, as I said in comment#9, the textual history
> indicates that the original intent of saying things are permitted
> here is *only* an exception to the general implementation-defined
> nature of type punning, not to any other reason why things might
> be undefined (such as aliasing rules, data races, etc.).

I went back and read through your earlier comments more carefully.
After that I also reviewed C90, N869, C99, N1124, N1256, DR 236,
DR 257, DR 283, and C11 (in the guise of the just-pre-C11 draft
N1570).

Let me say first that I agree with you that the Semantics section
of the member access operators (. and ->) needs at least some
revision and clarification.

Having said that, let me offer several more detailed responses
and/or comments.

One:  IME later versions of the C standard generally do a better
job of expressing what is intended than earlier versions do.

Two:  The "visible union" condition in C99 was viewed not as a
change to C90 but as correcting an oversight;  it was expected
all along that the union type would be in scope, even if the
expectation was not a conscious one originally.  I am sorry I
don't have a reference handy for this, but one can be found
digging around in the historical documents on the open-std.org
website.

Three:  The "one special guarantee" rule is independent of the
rules for effective types.  This observation is obviously right
because effective type rules matter only for access to objects.
The only objects being accessed under the "one special guarantee"
rule are guaranteed to have compatible types, which is always
allowed by effective type rules.

Four:  The "one special guarantee" rule is related to the area of
"type punning" through unions, but seen by WG14 as a separate
issue relative to the general topic.  This is evident from the
committee response in DR 257.

Five:  The footnote added in C99 TC3 about type punning is seen
by WG14 not as a change but just as a clarifying comment noting
what behavior was intended all along.  This is evident from the
text and response in DR 283.  Note that Clark Nelson, the author
of this DR, is a long-standing member of WG14, and the suggested
revision given in the text was adopted verbatim for the TC.

Six:  A key question here is What is the point or purpose of the
"one special guarantee" rule in the first place?  the Standard
doesn't say, but let me propose two likely motivations.

    1. Normally objects may be assumed not to overlap unless
    they are accessed through an explicit union membership
    expression (or through a character type, etc).  The "one
    special guarantee" rule identifies a case where an explicit
    union membership expression is not needed.

    2. The C standard distinctly allows any amount of padding
    between consecutive members of a struct.  Without the "one
    special guarantee" rule, there would be no way to be sure
    that the offsets of the respective members would match in
    all cases.  The "one special guarantee" rule has the effect
    of forcing offsets of struct members in a common initial
    sequence to be the same.  That is important for code
    portability.

Seven:  Given that the question is now under serious debate, IMO
someone involved with gcc development should take the initiative
and responsibility to submit a defect report in order to clarify
the issue.  Apparently other compilers don't have this problem -
only gcc does.

Eight:  In the meantime, the most prudent course of action is to
fix gcc so that it does not reorder code in cases like the above.
Whenever there is any doubt, the only sensible choice is to err
on the side of caution, and not perform any code transformations
that might not be allowed in a conforming implementation.  (Of
course it would be okay to perform such transformations under
some non-default compiler option, as long as it is not in force
unless explicitly requested, and clearly flagged as possibly
non-conforming.)

Nine:  Doing a final review, I realized I have not yet responded
directly to your last comment.  I agree with your general
sentiment that the "one special guarantee" rule is not meant as
a "super rule" that trumps all other possible reasons for
undefined behavior.  However, I do not agree with your primary
point that it is meant to be limited to the "type punning" area.
The example I previously mentioned in the C standard, and the
committee discussion in DR 257, both show that there are other
factors involved here beyond just those related to type punning.

I hope the above has helped clarify the matter.  I look forward
to reading your responding comments, if you have any.