* [PATCH v2] Fix -ffast-math flags handling inconsistencies
@ 2020-02-11 18:43 Ulrich Weigand
2020-02-11 23:56 ` Segher Boessenkool
2020-11-21 4:33 ` Jeff Law
0 siblings, 2 replies; 9+ messages in thread
From: Ulrich Weigand @ 2020-02-11 18:43 UTC (permalink / raw)
To: gcc-patches; +Cc: joseph, richard.guenther, segher
Hello,
this second version of the patch incorporates all changes discussed
in the original mail thread starting here:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02097.html
The patch now implements the following set of changes:
1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
is explicitly set (or reset) on the command line, this should override
any implicit change due to -f(no-)fast-math, no matter in which order
the flags come on the command line. This change affects all flags.
2. Any component flag modified from its default by -ffast-math should
be reset to the default by -fno-fast-math. This was previously
not done for the following flags:
-fcx-limited-range
-fexcess-precision=
3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has
no meaning (if we have no NaNs at all, it does not matter whether
there is a difference between quiet and signaling NaNs). Therefore,
it does not make sense for -ffast-math to imply -fno-signaling-nans.
This is also a documentation change.
4. -ffast-math is documented to imply -fno-rounding-math, however the
latter setting is the default anyway; therefore it does not make
sense to try to modify it from its default setting.
5. The __FAST_MATH__ preprocessor macro should be defined if and only
if all the component flags of -ffast-math are set to the value that
is documented as the effect of -ffast-math. The following flags
were currently *not* so tested:
-fcx-limited-range
-fassociative-math
-freciprocal-math
-frounding-math
(Note that we should still *test* for -fno-rounding-math here even
though it is not set as per 4. -ffast-math -frounding-math should
not set the __FAST_MATH__ macro.)
This is also a documentation change.
Tested on s390x-ibm-linux.
OK for mainline?
Bye,
Ulrich
gcc/ChangeLog:
* doc/invoke.texi (-ffast-math): Remove mention of -fno-signaling-nans.
Clarify conditions when __FAST_MATH__ preprocessor macro is defined.
* opts.c (common_handle_option): Pass OPTS_SET to set_fast_math_flags
and set_unsafe_math_optimizations_flags.
(set_fast_math_flags): Add OPTS_SET argument, and use it to avoid
setting flags already explicitly set on the command line. In the !set
case, also reset x_flag_cx_limited_range and x_flag_excess_precision.
Never reset x_flag_signaling_nans or x_flag_rounding_math.
(set_unsafe_math_optimizations_flags): Add OPTS_SET argument, and use
it to avoid setting flags already explicitly set on the command line.
(fast_math_flags_set_p): Also test x_flag_cx_limited_range,
x_flag_associative_math, x_flag_reciprocal_math, and
x_flag_rounding_math.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2cd8d7ec5ff..662fded21ea 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -11441,10 +11441,10 @@ is unpredictable.
@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}.
+@option{-fcx-limited-range} and @option{-fexcess-precision=fast}.
-This option causes the preprocessor macro @code{__FAST_MATH__} to be defined.
+Whenever all these options listed above are set to those values,
+the preprocessor macro @code{__FAST_MATH__} will be defined.
This option is not turned on by any @option{-O} option besides
@option{-Ofast} since it can result in incorrect output for programs
diff --git a/gcc/opts.c b/gcc/opts.c
index 7affeb41a96..5a2ae9631ab 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -192,10 +192,12 @@ static void set_debug_level (enum debug_info_type type, int extended,
const char *arg, struct gcc_options *opts,
struct gcc_options *opts_set,
location_t loc);
-static void set_fast_math_flags (struct gcc_options *opts, int set);
+static void set_fast_math_flags (struct gcc_options *opts,
+ struct gcc_options *opts_set, int set);
static void decode_d_option (const char *arg, struct gcc_options *opts,
location_t loc, diagnostic_context *dc);
static void set_unsafe_math_optimizations_flags (struct gcc_options *opts,
+ struct gcc_options *opts_set,
int set);
static void enable_warning_as_error (const char *arg, int value,
unsigned int lang_mask,
@@ -2447,11 +2449,11 @@ common_handle_option (struct gcc_options *opts,
break;
case OPT_ffast_math:
- set_fast_math_flags (opts, value);
+ set_fast_math_flags (opts, opts_set, value);
break;
case OPT_funsafe_math_optimizations:
- set_unsafe_math_optimizations_flags (opts, value);
+ set_unsafe_math_optimizations_flags (opts, opts_set, value);
break;
case OPT_ffixed_:
@@ -2839,44 +2841,44 @@ set_Wstrict_aliasing (struct gcc_options *opts, int onoff)
/* The following routines are useful in setting all the flags that
-ffast-math and -fno-fast-math imply. */
static void
-set_fast_math_flags (struct gcc_options *opts, int set)
+set_fast_math_flags (struct gcc_options *opts,
+ struct gcc_options *opts_set, int set)
{
- if (!opts->frontend_set_flag_unsafe_math_optimizations)
+ if (!opts->frontend_set_flag_unsafe_math_optimizations
+ && !opts_set->x_flag_unsafe_math_optimizations)
{
opts->x_flag_unsafe_math_optimizations = set;
- set_unsafe_math_optimizations_flags (opts, set);
+ set_unsafe_math_optimizations_flags (opts, opts_set, set);
}
if (!opts->frontend_set_flag_finite_math_only)
- opts->x_flag_finite_math_only = set;
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_finite_math_only, set);
if (!opts->frontend_set_flag_errno_math)
- opts->x_flag_errno_math = !set;
- if (set)
- {
- if (opts->frontend_set_flag_excess_precision == EXCESS_PRECISION_DEFAULT)
- opts->x_flag_excess_precision
- = set ? EXCESS_PRECISION_FAST : EXCESS_PRECISION_DEFAULT;
- 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;
- if (!opts->frontend_set_flag_cx_limited_range)
- opts->x_flag_cx_limited_range = 1;
- }
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_errno_math, !set);
+ if (!opts->frontend_set_flag_cx_limited_range)
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_cx_limited_range, set);
+ if (!opts->frontend_set_flag_excess_precision)
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_excess_precision,
+ set ? EXCESS_PRECISION_FAST
+ : EXCESS_PRECISION_DEFAULT);
+
+ // -ffast-math should also reset -frounding-math, but since this
+ // is off by default, there's nothing to do for now.
}
/* When -funsafe-math-optimizations is set the following
flags are set as well. */
static void
-set_unsafe_math_optimizations_flags (struct gcc_options *opts, int set)
+set_unsafe_math_optimizations_flags (struct gcc_options *opts,
+ struct gcc_options *opts_set, int set)
{
if (!opts->frontend_set_flag_trapping_math)
- opts->x_flag_trapping_math = !set;
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_trapping_math, !set);
if (!opts->frontend_set_flag_signed_zeros)
- opts->x_flag_signed_zeros = !set;
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_signed_zeros, !set);
if (!opts->frontend_set_flag_associative_math)
- opts->x_flag_associative_math = set;
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_associative_math, set);
if (!opts->frontend_set_flag_reciprocal_math)
- opts->x_flag_reciprocal_math = set;
+ SET_OPTION_IF_UNSET (opts, opts_set, flag_reciprocal_math, set);
}
/* Return true iff flags in OPTS are set as if -ffast-math. */
@@ -2884,10 +2886,14 @@ bool
fast_math_flags_set_p (const struct gcc_options *opts)
{
return (!opts->x_flag_trapping_math
+ && !opts->x_flag_signed_zeros
+ && opts->x_flag_associative_math
+ && opts->x_flag_reciprocal_math
&& opts->x_flag_unsafe_math_optimizations
&& opts->x_flag_finite_math_only
- && !opts->x_flag_signed_zeros
&& !opts->x_flag_errno_math
+ && !opts->x_flag_rounding_math
+ && opts->x_flag_cx_limited_range
&& opts->x_flag_excess_precision == EXCESS_PRECISION_FAST);
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-02-11 18:43 [PATCH v2] Fix -ffast-math flags handling inconsistencies Ulrich Weigand
@ 2020-02-11 23:56 ` Segher Boessenkool
2020-11-21 4:33 ` Jeff Law
1 sibling, 0 replies; 9+ messages in thread
From: Segher Boessenkool @ 2020-02-11 23:56 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: gcc-patches, joseph, richard.guenther
Hi!
On Tue, Feb 11, 2020 at 07:43:31PM +0100, Ulrich Weigand wrote:
> 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> is explicitly set (or reset) on the command line, this should override
> any implicit change due to -f(no-)fast-math, no matter in which order
> the flags come on the command line. This change affects all flags.
Ack.
> 2. Any component flag modified from its default by -ffast-math should
> be reset to the default by -fno-fast-math. This was previously
> not done for the following flags:
> -fcx-limited-range
> -fexcess-precision=
Ack.
> 3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has
> no meaning (if we have no NaNs at all, it does not matter whether
> there is a difference between quiet and signaling NaNs). Therefore,
> it does not make sense for -ffast-math to imply -fno-signaling-nans.
> This is also a documentation change.
Ack.
> 4. -ffast-math is documented to imply -fno-rounding-math, however the
> latter setting is the default anyway; therefore it does not make
> sense to try to modify it from its default setting.
Ack. It might be more robust to *do* set it, so that it still works if
the default ever changes.
> 5. The __FAST_MATH__ preprocessor macro should be defined if and only
> if all the component flags of -ffast-math are set to the value that
> is documented as the effect of -ffast-math. The following flags
> were currently *not* so tested:
> -fcx-limited-range
> -fassociative-math
> -freciprocal-math
> -frounding-math
> (Note that we should still *test* for -fno-rounding-math here even
> though it is not set as per 4. -ffast-math -frounding-math should
> not set the __FAST_MATH__ macro.)
> This is also a documentation change.
Ack.
All looks good to me, but I'm not maintainer of this.
This should be mentioned in the release notes I think, it does change
behaviour (for the better, but any change is a change).
Thanks,
Segher
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-02-11 18:43 [PATCH v2] Fix -ffast-math flags handling inconsistencies Ulrich Weigand
2020-02-11 23:56 ` Segher Boessenkool
@ 2020-11-21 4:33 ` Jeff Law
2020-11-21 19:57 ` Segher Boessenkool
2020-11-24 18:42 ` Ulrich Weigand
1 sibling, 2 replies; 9+ messages in thread
From: Jeff Law @ 2020-11-21 4:33 UTC (permalink / raw)
To: Ulrich Weigand, gcc-patches; +Cc: joseph, richard.guenther, segher
On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> Hello,
>
> this second version of the patch incorporates all changes discussed
> in the original mail thread starting here:
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg02097.html
>
> The patch now implements the following set of changes:
>
> 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> is explicitly set (or reset) on the command line, this should override
> any implicit change due to -f(no-)fast-math, no matter in which order
> the flags come on the command line. This change affects all flags.
>
> 2. Any component flag modified from its default by -ffast-math should
> be reset to the default by -fno-fast-math. This was previously
> not done for the following flags:
> -fcx-limited-range
> -fexcess-precision=
>
> 3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has
> no meaning (if we have no NaNs at all, it does not matter whether
> there is a difference between quiet and signaling NaNs). Therefore,
> it does not make sense for -ffast-math to imply -fno-signaling-nans.
> This is also a documentation change.
>
> 4. -ffast-math is documented to imply -fno-rounding-math, however the
> latter setting is the default anyway; therefore it does not make
> sense to try to modify it from its default setting.
>
> 5. The __FAST_MATH__ preprocessor macro should be defined if and only
> if all the component flags of -ffast-math are set to the value that
> is documented as the effect of -ffast-math. The following flags
> were currently *not* so tested:
> -fcx-limited-range
> -fassociative-math
> -freciprocal-math
> -frounding-math
> (Note that we should still *test* for -fno-rounding-math here even
> though it is not set as per 4. -ffast-math -frounding-math should
> not set the __FAST_MATH__ macro.)
> This is also a documentation change.
>
>
> Tested on s390x-ibm-linux.
>
> OK for mainline?
>
> Bye,
> Ulrich
>
> gcc/ChangeLog:
>
> * doc/invoke.texi (-ffast-math): Remove mention of -fno-signaling-nans.
> Clarify conditions when __FAST_MATH__ preprocessor macro is defined.
>
> * opts.c (common_handle_option): Pass OPTS_SET to set_fast_math_flags
> and set_unsafe_math_optimizations_flags.
> (set_fast_math_flags): Add OPTS_SET argument, and use it to avoid
> setting flags already explicitly set on the command line. In the !set
> case, also reset x_flag_cx_limited_range and x_flag_excess_precision.
> Never reset x_flag_signaling_nans or x_flag_rounding_math.
> (set_unsafe_math_optimizations_flags): Add OPTS_SET argument, and use
> it to avoid setting flags already explicitly set on the command line.
> (fast_math_flags_set_p): Also test x_flag_cx_limited_range,
> x_flag_associative_math, x_flag_reciprocal_math, and
> x_flag_rounding_math.
It appears this was dropped on the floor. It looks reasonable to me.
Please retest and commit. Thanks!
Jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-11-21 4:33 ` Jeff Law
@ 2020-11-21 19:57 ` Segher Boessenkool
2020-11-24 10:55 ` [wwwdocs] " Ulrich Weigand
2020-11-24 18:42 ` Ulrich Weigand
1 sibling, 1 reply; 9+ messages in thread
From: Segher Boessenkool @ 2020-11-21 19:57 UTC (permalink / raw)
To: Jeff Law; +Cc: Ulrich Weigand, gcc-patches, joseph, richard.guenther
Hi!
On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> > is explicitly set (or reset) on the command line, this should override
> > any implicit change due to -f(no-)fast-math, no matter in which order
> > the flags come on the command line. This change affects all flags.
> >
> > 2. Any component flag modified from its default by -ffast-math should
> > be reset to the default by -fno-fast-math. This was previously
> > not done for the following flags:
> > -fcx-limited-range
> > -fexcess-precision=
> >
> > 3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has
> > no meaning (if we have no NaNs at all, it does not matter whether
> > there is a difference between quiet and signaling NaNs). Therefore,
> > it does not make sense for -ffast-math to imply -fno-signaling-nans.
> > This is also a documentation change.
> >
> > 4. -ffast-math is documented to imply -fno-rounding-math, however the
> > latter setting is the default anyway; therefore it does not make
> > sense to try to modify it from its default setting.
> >
> > 5. The __FAST_MATH__ preprocessor macro should be defined if and only
> > if all the component flags of -ffast-math are set to the value that
> > is documented as the effect of -ffast-math. The following flags
> > were currently *not* so tested:
> > -fcx-limited-range
> > -fassociative-math
> > -freciprocal-math
> > -frounding-math
> > (Note that we should still *test* for -fno-rounding-math here even
> > though it is not set as per 4. -ffast-math -frounding-math should
> > not set the __FAST_MATH__ macro.)
> > This is also a documentation change.
> It appears this was dropped on the floor. It looks reasonable to me.
> Please retest and commit. Thanks!
It all makes sense, and is a nice improvement :-) But please mention it
in the release notes? No doubt people did use non-sensical flag
combinations, and they will be affected. Thanks!
Segher
^ permalink raw reply [flat|nested] 9+ messages in thread
* [wwwdocs] Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-11-21 19:57 ` Segher Boessenkool
@ 2020-11-24 10:55 ` Ulrich Weigand
2020-11-24 17:19 ` Segher Boessenkool
0 siblings, 1 reply; 9+ messages in thread
From: Ulrich Weigand @ 2020-11-24 10:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: law, gcc-patches, joseph, richard.guenther
On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> > > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> > > is explicitly set (or reset) on the command line, this should override
> > > any implicit change due to -f(no-)fast-math, no matter in which order
> > > the flags come on the command line. This change affects all flags.
> > >
> > > 2. Any component flag modified from its default by -ffast-math should
> > > be reset to the default by -fno-fast-math. This was previously
> > > not done for the following flags:
> > > -fcx-limited-range
> > > -fexcess-precision=
> > >
> > > 3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has
> > > no meaning (if we have no NaNs at all, it does not matter whether
> > > there is a difference between quiet and signaling NaNs). Therefore,
> > > it does not make sense for -ffast-math to imply -fno-signaling-nans.
> > > This is also a documentation change.
> > >
> > > 4. -ffast-math is documented to imply -fno-rounding-math, however the
> > > latter setting is the default anyway; therefore it does not make
> > > sense to try to modify it from its default setting.
> > >
> > > 5. The __FAST_MATH__ preprocessor macro should be defined if and only
> > > if all the component flags of -ffast-math are set to the value that
> > > is documented as the effect of -ffast-math. The following flags
> > > were currently *not* so tested:
> > > -fcx-limited-range
> > > -fassociative-math
> > > -freciprocal-math
> > > -frounding-math
> > > (Note that we should still *test* for -fno-rounding-math here even
> > > though it is not set as per 4. -ffast-math -frounding-math should
> > > not set the __FAST_MATH__ macro.)
> > > This is also a documentation change.
>
> > It appears this was dropped on the floor.? It looks reasonable to me.?
> > Please retest and commit.? Thanks!
I've now retested on s390x-ibm-linux and committed to mainline.
Thanks for the review!
> It all makes sense, and is a nice improvement :-) But please mention it
> in the release notes? No doubt people did use non-sensical flag
> combinations, and they will be affected. Thanks!
Here's a proposed patch to update the gcc-11 changes.hmtl.
OK to commit?
Bye,
Ulrich
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 46a6a37..c0f896a 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -58,6 +58,29 @@ a work-in-progress.</p>
is deprecated and will be removed in a future release. It should be
possible to use <code>--enable-cheaders=c_global</code> (the default)
with no change in behaviour. </li>
+
+ <li>Some inconsistencies in handling combinations of <code>-ffast-math</code>,
+ <code>-fno-fast-math</code>, <code>-funsafe-math-optimizations</code>,
+ <code>-fno-unsafe-math-optimizations</code>, and their component flags
+ have been fixed. This might change the behavior of the compiler when
+ invoked with certain combinations of such command line options.
+ The behavior is now consistently:
+ <ul>
+ <li>If a component flag of <code>-ffast-math</code> or
+ <code>-funsafe-math-optimizations</code> is explicitly set or reset
+ on the command line, this will override any implicit change, no matter
+ in which order the flags come on the command line.</li>
+ <li>Any component flag (which is not explicity set or reset on the command
+ line) that was modified from its default by <code>-ffast-math</code> or
+ <code>-funsafe-math-optimizations</code> is always reset to its default
+ by a subsequent <code>-fno-fast-math</code> or
+ <code>-fno-unsafe-math-optimizations</code>.</li>
+ <li><code>-ffast-math</code> no longer implicitly changes
+ <code>-fsignaling-math</code>.
+ <li>The <code>__FAST_MATH__</code> preprocessor macro is set if and
+ only if all component flags of <code>-ffast-math</code> are set
+ to the value documented as the effect of <code>-ffast-math</code>.</li>
+ </ul></li>
</ul>
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [wwwdocs] Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-11-24 10:55 ` [wwwdocs] " Ulrich Weigand
@ 2020-11-24 17:19 ` Segher Boessenkool
0 siblings, 0 replies; 9+ messages in thread
From: Segher Boessenkool @ 2020-11-24 17:19 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: law, gcc-patches, joseph, richard.guenther
Hi!
On Tue, Nov 24, 2020 at 11:55:23AM +0100, Ulrich Weigand wrote:
> On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote:
> > It all makes sense, and is a nice improvement :-) But please mention it
> > in the release notes? No doubt people did use non-sensical flag
> > combinations, and they will be affected. Thanks!
>
> Here's a proposed patch to update the gcc-11 changes.hmtl.
>
> OK to commit?
This looks perfect to me. It even looks like fine HTML (but I would
trust the W3C validator over me on that, hehe.
> diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
> index 46a6a37..c0f896a 100644
> --- a/htdocs/gcc-11/changes.html
> +++ b/htdocs/gcc-11/changes.html
> @@ -58,6 +58,29 @@ a work-in-progress.</p>
> is deprecated and will be removed in a future release. It should be
> possible to use <code>--enable-cheaders=c_global</code> (the default)
> with no change in behaviour. </li>
> +
> + <li>Some inconsistencies in handling combinations of <code>-ffast-math</code>,
> + <code>-fno-fast-math</code>, <code>-funsafe-math-optimizations</code>,
> + <code>-fno-unsafe-math-optimizations</code>, and their component flags
> + have been fixed. This might change the behavior of the compiler when
> + invoked with certain combinations of such command line options.
> + The behavior is now consistently:
> + <ul>
> + <li>If a component flag of <code>-ffast-math</code> or
(trailing space, if you care)
> + <code>-funsafe-math-optimizations</code> is explicitly set or reset
> + on the command line, this will override any implicit change, no matter
> + in which order the flags come on the command line.</li>
> + <li>Any component flag (which is not explicity set or reset on the command
> + line) that was modified from its default by <code>-ffast-math</code> or
> + <code>-funsafe-math-optimizations</code> is always reset to its default
> + by a subsequent <code>-fno-fast-math</code> or
> + <code>-fno-unsafe-math-optimizations</code>.</li>
> + <li><code>-ffast-math</code> no longer implicitly changes
> + <code>-fsignaling-math</code>.
> + <li>The <code>__FAST_MATH__</code> preprocessor macro is set if and
> + only if all component flags of <code>-ffast-math</code> are set
> + to the value documented as the effect of <code>-ffast-math</code>.</li>
> + </ul></li>
> </ul>
Thanks,
Segher
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-11-21 4:33 ` Jeff Law
2020-11-21 19:57 ` Segher Boessenkool
@ 2020-11-24 18:42 ` Ulrich Weigand
2020-11-24 23:23 ` Segher Boessenkool
2020-11-25 13:12 ` Christophe Lyon
1 sibling, 2 replies; 9+ messages in thread
From: Ulrich Weigand @ 2020-11-24 18:42 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches, joseph, richard.guenther, segher
On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > * doc/invoke.texi (-ffast-math): Remove mention of -fno-signaling-nans.
> > Clarify conditions when __FAST_MATH__ preprocessor macro is defined.
> >
> > * opts.c (common_handle_option): Pass OPTS_SET to set_fast_math_flags
> > and set_unsafe_math_optimizations_flags.
> > (set_fast_math_flags): Add OPTS_SET argument, and use it to avoid
> > setting flags already explicitly set on the command line. In the !set
> > case, also reset x_flag_cx_limited_range and x_flag_excess_precision.
> > Never reset x_flag_signaling_nans or x_flag_rounding_math.
> > (set_unsafe_math_optimizations_flags): Add OPTS_SET argument, and use
> > it to avoid setting flags already explicitly set on the command line.
> > (fast_math_flags_set_p): Also test x_flag_cx_limited_range,
> > x_flag_associative_math, x_flag_reciprocal_math, and
> > x_flag_rounding_math.
> It appears this was dropped on the floor. It looks reasonable to me.
> Please retest and commit. Thanks!
This did handle flag_excess_precision incorrectly, causing in particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970
I've reverted for now and will post a modified patch later.
Sorry for the breakage!
At a first glance, it appears the problem is that -fexcess-precision=fast
is already the default, so it does not make sense for -fno-fast-math to
"reset" this back to default. Probably the best is for fast-math to
simply not touch excess precision at all:
- if it is set explicitly on the command line, fast-math should not
affect it in any case;
- if it is not set explicitly on the command line, the default either
with fast-math or no-fast-math is excess-precision=fast, so again
it should not be touched.
I'll still need to look into the language-specific handling of the
excess precision setting to make sure this works for all languages.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-11-24 18:42 ` Ulrich Weigand
@ 2020-11-24 23:23 ` Segher Boessenkool
2020-11-25 13:12 ` Christophe Lyon
1 sibling, 0 replies; 9+ messages in thread
From: Segher Boessenkool @ 2020-11-24 23:23 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Jeff Law, gcc-patches, joseph, richard.guenther
Hi Ulrich,
On Tue, Nov 24, 2020 at 07:42:47PM +0100, Ulrich Weigand wrote:
> This did handle flag_excess_precision incorrectly, causing in particular
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970
>
> I've reverted for now and will post a modified patch later.
> Sorry for the breakage!
>
> At a first glance, it appears the problem is that -fexcess-precision=fast
> is already the default, so it does not make sense for -fno-fast-math to
> "reset" this back to default. Probably the best is for fast-math to
> simply not touch excess precision at all:
> - if it is set explicitly on the command line, fast-math should not
> affect it in any case;
> - if it is not set explicitly on the command line, the default either
> with fast-math or no-fast-math is excess-precision=fast, so again
> it should not be touched.
>
> I'll still need to look into the language-specific handling of the
> excess precision setting to make sure this works for all languages.
At least C uses "standard" (instead of "fast") for the strict ISO C
dialects.
Segher
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies
2020-11-24 18:42 ` Ulrich Weigand
2020-11-24 23:23 ` Segher Boessenkool
@ 2020-11-25 13:12 ` Christophe Lyon
1 sibling, 0 replies; 9+ messages in thread
From: Christophe Lyon @ 2020-11-25 13:12 UTC (permalink / raw)
To: Ulrich Weigand; +Cc: Jeff Law, gcc Patches, Segher Boessenkool, Joseph S. Myers
On Tue, 24 Nov 2020 at 19:43, Ulrich Weigand via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > > * doc/invoke.texi (-ffast-math): Remove mention of -fno-signaling-nans.
> > > Clarify conditions when __FAST_MATH__ preprocessor macro is defined.
> > >
> > > * opts.c (common_handle_option): Pass OPTS_SET to set_fast_math_flags
> > > and set_unsafe_math_optimizations_flags.
> > > (set_fast_math_flags): Add OPTS_SET argument, and use it to avoid
> > > setting flags already explicitly set on the command line. In the !set
> > > case, also reset x_flag_cx_limited_range and x_flag_excess_precision.
> > > Never reset x_flag_signaling_nans or x_flag_rounding_math.
> > > (set_unsafe_math_optimizations_flags): Add OPTS_SET argument, and use
> > > it to avoid setting flags already explicitly set on the command line.
> > > (fast_math_flags_set_p): Also test x_flag_cx_limited_range,
> > > x_flag_associative_math, x_flag_reciprocal_math, and
> > > x_flag_rounding_math.
> > It appears this was dropped on the floor. It looks reasonable to me.
> > Please retest and commit. Thanks!
>
> This did handle flag_excess_precision incorrectly, causing in particular
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970
>
> I've reverted for now and will post a modified patch later.
> Sorry for the breakage!
>
> At a first glance, it appears the problem is that -fexcess-precision=fast
> is already the default, so it does not make sense for -fno-fast-math to
> "reset" this back to default. Probably the best is for fast-math to
> simply not touch excess precision at all:
> - if it is set explicitly on the command line, fast-math should not
> affect it in any case;
> - if it is not set explicitly on the command line, the default either
> with fast-math or no-fast-math is excess-precision=fast, so again
> it should not be touched.
>
> I'll still need to look into the language-specific handling of the
> excess precision setting to make sure this works for all languages.
>
Hi Ulrich,
The patch you've reverted was also causing a regression on arm/aarch64:
FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline
"hooray[^\\n]*inline copy in test"
In case this helps you make tests.
Thanks,
Christophe
> Bye,
> Ulrich
>
> --
> Dr. Ulrich Weigand
> GNU/Linux compilers and toolchain
> Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-11-25 13:12 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-11 18:43 [PATCH v2] Fix -ffast-math flags handling inconsistencies Ulrich Weigand
2020-02-11 23:56 ` Segher Boessenkool
2020-11-21 4:33 ` Jeff Law
2020-11-21 19:57 ` Segher Boessenkool
2020-11-24 10:55 ` [wwwdocs] " Ulrich Weigand
2020-11-24 17:19 ` Segher Boessenkool
2020-11-24 18:42 ` Ulrich Weigand
2020-11-24 23:23 ` Segher Boessenkool
2020-11-25 13:12 ` Christophe Lyon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).