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: Tue, 21 Jan 2020 14:50:33 +0100 (CET)
- Subject: Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
Joseph Myers wrote:
> On Mon, 20 Jan 2020, Ulrich Weigand wrote:
> > This has the effect that e.g. after
> > -ffast-math -fno-finite-math-only
> > the __FAST_MATH__ macro is no longer predefined, but after
> > -ffast-math -fno-associative-math
> > the __FAST_MATH__ macro still *is* predefined, even though both
> > -ffinite-math-only and -fassociative-math are implied by -ffast-math.
> > Is this deliberate? (If so, is it documented somewhere?)
> I'd expect both to cause it to be undefined. My guess would be that some
> past patch, after fast_math_flags_set_p was added, added more flags to
> -ffast-math but accidentally failed to update fast_math_flags_set_p; you'd
> need to look at past patches adding flags to -ffast-math to confirm if
> it's accidental.
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
For the other three flags, -fsignaling-nans, -frounding-math, and
-fcx-limited-range, the story appears to be a bit different: from the
very beginning, those were treated somewhat differently: these are
only modified as a result of -ffast-math, not -fno-fast-math (like
the other flags derived from -ffast-math), and they are not considered
by fast_math_flags_set_p. (I'm not sure if there is any particular
reason why these should be treated differently here, though.)
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
Do you think there is something that ought to be fixed here?
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain