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-bugzi...@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.