Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Joseph Myers wrote:
> 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.

OK, agreed.

> > 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.

I see.  I guess that makes me wonder what -fno-fast-math *ever* does
(except canceling a -ffast-math earlier on the command line).  Looking
at the current code, -fno-fast-math (just like -ffast-math) only ever
sets flags whose default is not overridden on the command line, but
then it always sets them to their default value!

Am I missing something here?  If that's the intent, it might be cleaner
to write set_fast_math_flags as just one big
  if (set)
    {
    }

> 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.

OK.

> > 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.

This also makes sense if we consider the semantics of -fno-fast-math to
just leave all component flags at their default, as above ...

(As an aside, the current code is even more confusing as it has a dead
condition:

  if (set)
    {
      if (opts->frontend_set_flag_excess_precision == EXCESS_PRECISION_DEFAULT)
        opts->x_flag_excess_precision
          = set ? EXCESS_PRECISION_FAST : EXCESS_PRECISION_DEFAULT;

The second test of "set" must always be true here, so this will never actually
actively set the flag to EXCESS_PRECISION_DEFAULT.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com