https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990
--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Note the argument about nobody reads documentation does not hold much weight about doing what we think is right. If that was the argument then -fwrapv and -fno-strict-aliasing would be defaults in compilers for the last 20+ years. But it is not, GCC changed the default to strict-aliasing in 3.0.0 released in June 18, 2001. -fno-wrapv has been the defualt for GCC since before 2.95.2 but only since 4.1.0 (February 28, 2006) (when the VPR pass was introduced) that there has been so many more reports about signed integer overflow being undefined. GCC gets many more reports about signed integer overflow being undefined than -Ofast issues. Even more reports about strict aliasing issues too. This is not just 2x but closer to a 10x. Most of the -Ofast issues are more reported by GCC developers when they notice SPEC benchmarks no longer works with it rather any other reports. And this is more to record the issue with that you no longer use -Ofast there rather than anything else. Note there are some strict aliasing issues in SPEC too; e.g. even in GCC that is included in SPEC 2017 is broken (see PR 115256 [Fixed by PR 48981] and PR 88900 [Fixed in freebsd qsort in https://github.com/freebsd/freebsd/commit/26c8a03901f609258e58c4e3bfdc981962a638f0#diff-a8e4a78e4bb28c6e0fe9561688f51573; since that is where spec_qsort was copied from] ). Should we deprecate the use of -fstrict-aliasing then? If only the documentation argument is used then YES. But this shows why the documentation argument does not hold water and should not be used as the main driver here.
