On Mon, 29 Sep 2014, Steven Bosscher wrote: > On Mon, Sep 29, 2014 at 12:09 AM, FX wrote: > > Filed as PR63401: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401 > > > > > >> This is easy to see with a simple C test case: > >> > >> //__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 (chosen because it’s > >> actually useless), 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. > >> > >> I’m CC’ing the maintainers who added the optimize attribute in the first > >> place, as they might have an idea how to fix this. This is way beyond my > >> league! > > Perhaps Joseph can help, in his position as maintainer of the option > handling subsystem.
Bug 38716 is a similar issue. I think of this as being about which options take priority in determining the final setting of some gcc_options field. You want options implied by -Osomething not to override anything set explicitly. Properly, this requires the opts_set gcc_options structure to be used to store not booleans (explicitly set / not) but information about the priority with which something was set (distance as in appendix 1 of <https://gcc.gnu.org/ml/gcc/2010-01/msg00063.html>). (This mainly shows up with the optimize attribute because otherwise the optimization level gets processed before other options.) You may however be able to fix some cases with smaller changes: * Avoid reprocessing the existing optimization level if the attribute doesn't specify any optimization level. * Don't override any option that was explicitly set when processing the optimization level. (By itself this won't help with -ffast-math because the issue is overriding all the other options implicitly set with -ffast-math. But as long as -ffast-math itself doesn't respect the rule that more specific options override less specific ones, whatever the command-line ordering, you could just as well change set_fast_math_flags to take opts_set as well and mark the options in question explicitly set, unless any other code checks if they were explicitly set and so would regress from such a change.) -- Joseph S. Myers jos...@codesourcery.com