https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 27 Sep 2017, david at westcontrol dot com wrote: > 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. Unfortunately it's not the "last bit of performance", otherwise it would be indeed a no-brainer. People expect fast code from a compiler and do not want to enable dozens of -fIm-writing-reasonable-code. Some benchmarks even have rules as to how many options you are allowed to enable... Richard.
