Bug 63401 - "optimize" attribute overwrites other options
Summary: "optimize" attribute overwrites other options
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 38716 (view as bug list)
Depends on:
Blocks: 38716
  Show dependency treegraph
 
Reported: 2014-09-28 22:08 UTC by Francois-Xavier Coudert
Modified: 2020-02-25 10:15 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.8.0, 4.9.0, 5.0
Last reconfirmed: 2014-09-28 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francois-Xavier Coudert 2014-09-28 22:08:00 UTC
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.
Comment 1 Steven Bosscher 2014-09-28 22:14:51 UTC
Fails with all GCC releases that support the 'optimize' attribute
(GCC4.4 and later).
Comment 2 rsandifo@gcc.gnu.org 2020-02-25 10:15:15 UTC
*** Bug 38716 has been marked as a duplicate of this bug. ***