Richard Biener wrote:
> On Fri, Jan 31, 2020 at 6:01 PM Ulrich Weigand <uweig...@de.ibm.com> wrote:
> > The overall effect of this patch is that now all component flags of
> > -ffast-math are treated exactly equivalently:
> > * they are set (changed from their default) with -ffast-math
> > * they are reset to their default with -fno-fast-math
> > * __FAST_MATH__ is only defined if the value of the flag matches
> > what -ffast-math would have set it to
>
> The last part is not obviously correct to me since it doesn't match
> documentation which says
>
> @item -ffast-math
> @opindex ffast-math
> Sets the options @option{-fno-math-errno},
> @option{-funsafe-math-optimizations},
> @option{-ffinite-math-only}, @option{-fno-rounding-math},
> @option{-fno-signaling-nans}, @option{-fcx-limited-range} and
> @option{-fexcess-precision=fast}.
>
> This option causes the preprocessor macro @code{__FAST_MATH__} to be defined.
>
> to me this reads as -ffast-math -fexcess-precision=standard defines
> __FAST_MATH__.
> The only relevant part to define __FAST_MATH__ is specifying -ffast-math,
> other
> options are not relevant (which of course is contradicted by
> implementation - where
> I didn't actually follow its history in that respect). So can you
> adjust documentation
> as to when exactly __FAST_MATH__ is defined?
Agreed. This should probably be worded something along the lines of:
"Whenever all of those options are set to these values as listed above,
the preprocessor macro @code{__FAST_MATH__} will be defined."
> > - if (!opts->frontend_set_flag_signaling_nans)
> > - opts->x_flag_signaling_nans = 0;
> > - if (!opts->frontend_set_flag_rounding_math)
> > - opts->x_flag_rounding_math = 0;
[...]
> > + // -ffast-math should also reset -fsignaling-nans and -frounding-math,
> > + // but since those are off by default, there's nothing to do for now.
> ...
>
> but what happens to -fsignalling-nans -ffast-math then? Better leave those
> in I'd say.
Ah, it seems I was confused about the intended semantics here.
I thought that a *more specific* option like -fsignalling-nans was always
intended to override a more generic option like -ffast-math, no matter
whether it comes before or after it on the command line.
Is it instead the case that the intended behavior is the generic option
overrides the specific option if the generic option comes later on the
command line?
In that case, I agree that those should be left in.
However, then I think it would be good to add tests for
!flag_signaling_nans / !flag_rounding_math to fast_math_flags_set_p,
because with these options on, we aren't really in fast-math territory
any more ...
> Note frontends come into play with what is considered -ffast-math
> and -fno-fast-math but below flags are tested irrespectively of that
> interpretation.
>
> Note there's -fcx-fortran-rules similar to -fcx-limited-range but not tested
> above. The canonical middle-end "flag" to look at is flag_complex_method.
> Somehow -fcx-fortran-rules doesn't come into play at all above but it
> affects -fcx-limited-range in another inconsistent way in that
> -fcx-limited-range -fcx-fortran-rules and -fcx-fortran-rules
> -fcx-limited-range
> behave the same (-fcx-fortran-rules takes precedence...). I guess
> -fcomplex-method=ENUM should be exposed and -fcx-* made
> appropriate aliases here.
I agree it would probably be the best if to use a -fcomplex-method=...
flag, handled analogously to -fexcess-precision in that it defaults to
an explicit DEFAULT value; unless this is overridden by an explicit
command line flag, the language front-end can then choose what DEFAULT
means for this particular language.
However, I'd prefer to not include that change into this patch as well :-)
This patch only changes the behavior related to -fcx-limited-range in one
very special case (-Ofast -fno-fast-math), where it makes it strictly
better. It should not affect the (existing) interaction with
-fcx-fortran-rules at all -- so anything to improve this can be done
in a separate patch, I think.
> You're tapping into a mine-field ;)
That's for sure :-)
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
