This is the mail archive of the gcc-bugs@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]

[Bug middle-end/63401] New: "optimize" attribute overwrites other options


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401

            Bug ID: 63401
           Summary: "optimize" attribute overwrites other options
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxcoudert at gcc dot gnu.org

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.

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