https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
David Brown <david at westcontrol dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david at westcontrol dot com --- Comment #26 from David Brown <david at westcontrol dot com> --- (In reply to rguent...@suse.de from comment #24) > On Wed, 2 Nov 2016, txr at alumni dot caltech.edu wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 > > > > --- Comment #22 from Tim Rentsch <txr at alumni dot caltech.edu> --- > > [responding to comments from rguent...@suse.de in Comment 20] > > > > > GCC already implements this if you specify -fno-strict-aliasing. > > > > The main point of my comments is that the ISO C standard requires > > the behavior in this case (and similar cases) be defined and not > > subject to any reordering. In other words the result must be the > > same as an unoptimized version. If a -fstrict-aliasing gcc /does/ > > transform the code so that the behavior is not the same as an > > unoptimized version, then gcc is not a conforming implementation. > > GCC has various optimization options that make it a not strictly > conforming implementation (-ffast-math for example), various > GNU extensions to the language, etc. > > > Or is it your position that gcc is conforming only when operated > > in the -fno-strict-aliasing mode? That position seems contrary to > > the documented description of the -fstrict-aliasing option. > > Well, N685 is still disputed in this bug. I was just pointing out > that GCC has a switch to make it conforming to your interpretation > of the standard (and this switch is the default at -O0 and -O1). A key difference with non-conformance options like -ffast-math is that these are not default options. A user must actively choose to use them. A user should not need particular options in order to get correct object code from their correct source code - or at least the user should get obvious error messages when using default options but where their source code hits an oddity in gcc (as they would get if they happened to use a gcc extension keyword like "asm" as an identifier in conforming C code). What should not happen is for the compiler to silently break good code unless the user has given specific flags. I am not sure whether this particular case really is a bug or not. However, I wonder if there has been too much emphasis on trying to understand exactly what the standards say. If the gcc developers here, who are amongst the most knowledgeable C and C++ experts around, have trouble with the details - then consider the position of the average C developer. Maybe it is better to try see it from their viewpoint - would a programmer expect these accesses to alias or not? If it is likely that programmers would expect aliasing here, and see that behaviour in other compilers, then the /useful/ default behaviour for gcc would be to treat code in the way programmers expect - even with -O3. Then have a "-fI-know-what-I-am-doing" flag for those that want to squeeze out the last bit of performance.