This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Improving GCC8 default option settings


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]