https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Tim Rentsch <txr at alumni dot caltech.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |txr at alumni dot caltech.edu
--- Comment #18 from Tim Rentsch <txr at alumni dot caltech.edu> ---
I would like to add a few comments to the discussion.
One: C and C++ are different in how they treat unions. My comments
here are about C. I believe they apply to C++ as well, but I am not
as familiar with the C++ standard as the C standard, so please take
that into consideration.
Two: I have recently posted a comment for Bug 14319. That comment
explains my reasoning why these two bugs should be separated and
not be considered duplicates.
Three: I note the comments made by joseph with regard to the .s1/.s2
matter. There may be a larger open question there, but to avoid
muddying the waters please assume that his change to use .s2 in the
initializer has been made.
Four: I understand that there are also larger issues related to how
union membership may have a bearing on alias analysis. My comments
here are confined to the particular case at hand, namely, given a
definition for union U followed by a definition for function f(),
could f() be optimized so the p1->m value is cached in a register
(or something similar) before the body of the if() is executed,
and the cached value used as the return value.
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,
and as there are no other conditions present that cause undefined
or unspecified behavior, the behavior is well-defined, which means
any optimization that changes the unoptimized behavior is wrong.
Six: To see the example code is covered under the "one special
guarantee" clause, note the second part of EXAMPLE 3 in 6.5.2.3.
In particular, the commentary in parentheses, "(because the union
type is not visible within function f)", shows that whether the
union type is defined before or after f() is the determining
factor here. Whether a . or -> union membership operation is
present or not present has no bearing on the definedness of
the struct member access p1->m.
Seven: I understand the objections about impacting alias analysis
and so forth. I agree that it makes the analysis more difficult
(although not as sweeping in its implications as some comments
imply). Despite the problems, the examples in the Standard, and
also the response to DR 257, both show that the committee members
fully intend that this case be covered under the "one special
guarantee" clause.
Eight: In the meantime, I strongly recommend gcc be patched to
support the expected decision (which is the more conservative
choice) rather than suspending activity until some indefinite
time in the future.
