[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 #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On November 1, 2016 7:16:06 PM GMT+01:00, "txr at alumni dot caltech.edu"
<gcc-bugzilla@gcc.gnu.org> wrote:
>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.

GCC already implements this if you specify -fno-strict-aliasing.