This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/63401] New: "optimize" attribute overwrites other options
- From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 28 Sep 2014 22:08:00 +0000
- Subject: [Bug middle-end/63401] New: "optimize" attribute overwrites other options
- Auto-submitted: auto-generated
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.