This is the mail archive of the
mailing list for the GCC project.
Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: joseph at codesourcery dot com (Joseph Myers)
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 27 Jan 2020 19:26:12 +0100 (CET)
- Subject: Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
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.
> > 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
> 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.
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
if (opts->frontend_set_flag_excess_precision == EXCESS_PRECISION_DEFAULT)
= 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.)
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain