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

Re: Is "optimize" attribute on fndecl handled differently?


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
joseph@codesourcery.com

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