fast_math_flags_set_p vs. set_fast_math_flags inconsistency?

[Joseph Myers]

On Tue, 21 Jan 2020, Ulrich Weigand wrote:

> It looks like there's multiple cases here.  For the two flags
> -fassociative-math and -freciprocal-math, it seems to have happened just as
> you describe: they were created (split out of -funsafe-math-optimizations)
> in commit a1a826110720eda37c73f829daa4ee243ee953f5, which however did not
> update fast_math_flags_set_p.

So that's a bug.

> For the other three flags, -fsignaling-nans, -frounding-math, and
> -fcx-limited-range, the story appears to be a bit different: from the

The first two of those are disabled by default as well as disabled by 
-ffast-math, so it seems right that -fno-fast-math does nothing with them 
and that they aren't checked by fast_math_flags_set_p.

The last one is disabled by default but enabled by -ffast-math.  So it 
would seem appropriate to handle it like other such options, disable it 
with -fno-fast-math, and check it in fast_math_flags_set_p.

> Finally, there is one "mixed" flag, -fexcess-precision, which is handled
> like the above three in that its default is only modified as a result of
> -ffast-math, not -fno-fast-math; but nevertheless this flag *is* checked
> in fast_math_flags_set_p.

That one's trickier because the default depends on whether a C standards 
conformance mode is specified.

-- 
Joseph S. Myers
joseph@codesourcery.com