I stumbled onto this bug while implementing some IEEE features in the Fortran front-end, where we need to compile certain functions with specific options to ensure full IEEE conformance. The backstory is here: https://gcc.gnu.org/ml/gcc/2014-09/msg00396.html

Take this two-line C code:

//__attribute__ ((optimize("strength-reduce")))
int foo (float x) { return __builtin_isnan(x); }

Compiled with -O3 -ffast-math, the isnan is simplified out (fast math means no NaNs). If you uncomment the attribute (I chose -fstrength-reduce because it's actually a NOP), and compile again with -O3 -ffast-math: the isnan test is not simplified any more.

This is because the codepath through default_options_optimization() has overwritten the value of the flags handled in set_fast_math_flags(): flag_finite_math_only, flag_signed_zeros, flag_trapping_math and flag_unsafe_math_optimizations.

In more detail: opts.c:set_fast_math_flags() is called three times:

  1. first, from toplev_main -> decode_options -> default_options_optimization -> handle_generated_option -> handle_option -> common_handle_option
  2. then, from toplev_main -> decode_options -> read_cmdline_option -> handle_option -> common_handle_option
  3. then, from my own build_function_decl -> parse_optimize_options -> decode_options -> default_options_optimization -> handle_generated_option -> handle_option -> common_handle_option

At 1 and 3, it’s called with value = 0, and at 2, with value = 1. So it is indeed a bug: because we re-parse the defaults at 3, we reset some of the flags dependent on -ffast-math (the ones quoted before), overwriting their earlier value.




PS: There is also something similar with align_functions/align_jumps/align_loops flags, but I don’t have time to chase it right now.