On Tue, 12 Sep 2017, Wilco Dijkstra wrote: > * Make -fno-math-errno the default - this mostly affects the code generated > for > sqrt, which should be treated just like floating point division and not set > errno by default (unless you explicitly select C89 mode).
(note that this can be selectively enabled by targets where libm never sets errno in the first place, docs call out Darwin as one such target, but musl-libc targets have this property too) > * Make -fno-trapping-math the default - another obvious one. From the docs: > "Compile code assuming that floating-point operations cannot generate > user-visible traps." > There isn't a lot of code that actually uses user-visible traps (if any - > many CPUs don't even support user traps as it's an optional IEEE feature). > So assuming trapping math by default is way too conservative since there is > no obvious benefit to users. OTOH -O options are understood to _never_ sacrifice standards compliance, with the exception of -Ofast. I believe that's an important property to keep. Maybe it's possible to treat -fno-trapping-math similar to -ffp-contract=fast, i.e. implicitly enable it in the default C-with-GNU-extensions mode, keeping strict-compliance mode (-std=c11 as opposed to gnu11) untouched? In any case it shouldn't be hard to issue a warning if fenv.h functions are used when -fno-trapping-math/-fno-rounding-math is enabled. If the above doesn't fly, I believe adopting and promoting a single option for non-value-changing math optimizations (-fno-math-errno -fno-trapping-math, plus -fno-rounding-math -fno-signaling-nans when they're no longer default) would be nice. > * Make -fno-common the default - this was originally needed for pre-ANSI C, > but > is optional in C (not sure whether it is still in C99/C11). This can > significantly improve code generation on targets that use anchors for > globals > (note the linker could report a more helpful message when ancient code that > requires -fcommon fails to link). I think in ISO C situations where -fcommon allows link to succeed fall under undefined behavior, which in GNU toolchain is defined to match the historical behavior. I assume the main issue with this is the amount of legacy code that would cause a link failure if -fno-common is made default - thus, is there anybody in position to trigger a full-distro rebuild with gcc patched to enable -fno-common, and compare before/after build failure stats? Thanks. Alexander
