public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
@ 2023-01-15 10:27 Aldy Hernandez
  0 siblings, 0 replies; 4+ messages in thread
From: Aldy Hernandez @ 2023-01-15 10:27 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Richard Biener, Andrew MacLeod, GCC patches, Aldy Hernandez

As discussed in the PR, for trapping math, do not fold overflowing
operations into +-INF as doing so could elide a trap.

There is a minor adjustment to known_isinf() where it was mistakenly
returning true for an [infinity U NAN], whereas it should only return
true when the range is exclusively +INF or -INF.  This is benign, as
there were no users of known_isinf up to now.

I had some testsuite issues with:

> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++14  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++17  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++20  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++98  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: g++.dg/pr71488.C   (test for excess errors)
> FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -Wc++-compat   scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
< FAIL: g++.dg/pr71488.C   (test for excess errors)
< FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
> FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments
> FAIL: go.test/test/fixedbugs/issue27836.dir/Äfoo.go  -O -I. (test for excess errors)
> FAIL: go.test/test/fixedbugs/issue27836.dir/Ämain.go  -O -I. (test for excess errors)

But they seem to be transient issues on my machine, as re-running them
manually don't cause any issues.  Also, the tests themselves have
nothing to do with floats so I don't see how they could be related.

Tested on x86-64 Linux.

I also ran the glibc testsuite (git sources) on x86-64 and this patch
fixes:

-FAIL: math/test-double-lgamma
-FAIL: math/test-double-log1p
-FAIL: math/test-float-lgamma
-FAIL: math/test-float-log1p
-FAIL: math/test-float128-catan
-FAIL: math/test-float128-catanh
-FAIL: math/test-float128-lgamma
-FAIL: math/test-float128-log
-FAIL: math/test-float128-log1p
-FAIL: math/test-float128-y0
-FAIL: math/test-float128-y1
-FAIL: math/test-float32-lgamma
-FAIL: math/test-float32-log1p
-FAIL: math/test-float32x-lgamma
-FAIL: math/test-float32x-log1p
-FAIL: math/test-float64-lgamma
-FAIL: math/test-float64-log1p
-FAIL: math/test-float64x-lgamma
-FAIL: math/test-ldouble-lgamma

OK for trunk?

	PR tree-optimization/107608

gcc/ChangeLog:

	* range-op-float.cc (range_operator_float::fold_range): Avoid
	folding into INF when flag_trapping_math.
	* value-range.h (frange::known_isinf): Return false for possible NANs.
---
 gcc/range-op-float.cc | 21 +++++++++++++++++++++
 gcc/value-range.h     |  1 +
 2 files changed, 22 insertions(+)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 986a3896a4f..74ac4658378 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -91,6 +91,27 @@ range_operator_float::fold_range (frange &r, tree type,
   else
     r.clear_nan ();
 
+  // If the result has overflowed and flag_trapping_math, folding this
+  // operation could elide an overflow or division by zero exception.
+  // Avoid returning a singleton +-INF, to keep the propagators (DOM
+  // and substitute_and_fold_engine) from folding.  See PR107608.
+  if (flag_trapping_math
+      && MODE_HAS_INFINITIES (TYPE_MODE (type))
+      && r.known_isinf () && !op1.known_isinf () && !op2.known_isinf ())
+    {
+      REAL_VALUE_TYPE inf = r.lower_bound ();
+      if (real_isneg (&inf))
+	{
+	  REAL_VALUE_TYPE min = real_min_representable (type);
+	  r.set (type, inf, min);
+	}
+      else
+	{
+	  REAL_VALUE_TYPE max = real_max_representable (type);
+	  r.set (type, max, inf);
+	}
+    }
+
   return true;
 }
 
diff --git a/gcc/value-range.h b/gcc/value-range.h
index ea50ed3e64a..f4ac73b499f 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -1300,6 +1300,7 @@ inline bool
 frange::known_isinf () const
 {
   return (m_kind == VR_RANGE
+	  && !maybe_isnan ()
 	  && real_identical (&m_min, &m_max)
 	  && real_isinf (&m_min));
 }
-- 
2.39.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
  2023-01-15 12:18 ` Jakub Jelinek
@ 2023-01-15 16:53   ` Aldy Hernandez
  0 siblings, 0 replies; 4+ messages in thread
From: Aldy Hernandez @ 2023-01-15 16:53 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Richard Biener, Andrew MacLeod, GCC patches



On 1/15/23 13:18, Jakub Jelinek wrote:
> On Sun, Jan 15, 2023 at 11:32:27AM +0100, Aldy Hernandez wrote:
>> As discussed in the PR, for trapping math, do not fold overflowing
>> operations into +-INF as doing so could elide a trap.
>>
>> There is a minor adjustment to known_isinf() where it was mistakenly
>> returning true for an [infinity U NAN], whereas it should only return
>> true when the range is exclusively +INF or -INF.  This is benign, as
>> there were no users of known_isinf up to now.
>>
>> I had some testsuite issues with:
>>
>>> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++14  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
>>> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++17  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
>>> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++20  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
>>> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++98  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
>>> FAIL: g++.dg/pr71488.C   (test for excess errors)
>>> FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
>>> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -Wc++-compat   scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
>> < FAIL: g++.dg/pr71488.C   (test for excess errors)
>> < FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
>>> FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments
>>> FAIL: go.test/test/fixedbugs/issue27836.dir/Äfoo.go  -O -I. (test for excess errors)
>>> FAIL: go.test/test/fixedbugs/issue27836.dir/Ämain.go  -O -I. (test for excess errors)
>>
>> But they seem to be transient issues on my machine, as re-running them
>> manually don't cause any issues.  Also, the tests themselves have
>> nothing to do with floats so I don't see how they could be related.
>>
>> Tested on x86-64 Linux.
>>
>> I also ran the glibc testsuite (git sources) on x86-64 and this patch
>> fixes:
>>
>> -FAIL: math/test-double-lgamma
>> -FAIL: math/test-double-log1p
>> -FAIL: math/test-float-lgamma
>> -FAIL: math/test-float-log1p
>> -FAIL: math/test-float128-catan
>> -FAIL: math/test-float128-catanh
>> -FAIL: math/test-float128-lgamma
>> -FAIL: math/test-float128-log
>> -FAIL: math/test-float128-log1p
>> -FAIL: math/test-float128-y0
>> -FAIL: math/test-float128-y1
>> -FAIL: math/test-float32-lgamma
>> -FAIL: math/test-float32-log1p
>> -FAIL: math/test-float32x-lgamma
>> -FAIL: math/test-float32x-log1p
>> -FAIL: math/test-float64-lgamma
>> -FAIL: math/test-float64-log1p
>> -FAIL: math/test-float64x-lgamma
>> -FAIL: math/test-ldouble-lgamma
>>
>> OK for trunk?
>>
>> 	PR tree-optimization/107608
>>
>> gcc/ChangeLog:
>>
>> 	* range-op-float.cc (range_operator_float::fold_range): Avoid
>> 	folding into INF when flag_trapping_math.
>> 	* value-range.h (frange::known_isinf): Return false for possible NANs.
> 
> As a workaround this looks ok to me, but we need to figure out something
> better for GCC 14.

Agreed.

I think the underlying problem is that we have little or inconsistent 
support for propagating floats.  It's not a ranger issue, but all the 
levels above it (and even the gimplifier) which seem to do their own 
thing wrt when they propagate or not.

FWIW, I still think the issue is DCE and friends which are removing 
trapping statements, but I'm happy to entertain other solutions.

Aldy


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
  2023-01-15 10:32 Aldy Hernandez
@ 2023-01-15 12:18 ` Jakub Jelinek
  2023-01-15 16:53   ` Aldy Hernandez
  0 siblings, 1 reply; 4+ messages in thread
From: Jakub Jelinek @ 2023-01-15 12:18 UTC (permalink / raw)
  To: Aldy Hernandez; +Cc: Richard Biener, Andrew MacLeod, GCC patches

On Sun, Jan 15, 2023 at 11:32:27AM +0100, Aldy Hernandez wrote:
> As discussed in the PR, for trapping math, do not fold overflowing
> operations into +-INF as doing so could elide a trap.
> 
> There is a minor adjustment to known_isinf() where it was mistakenly
> returning true for an [infinity U NAN], whereas it should only return
> true when the range is exclusively +INF or -INF.  This is benign, as
> there were no users of known_isinf up to now.
> 
> I had some testsuite issues with:
> 
> > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++14  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++17  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++20  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++98  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> > FAIL: g++.dg/pr71488.C   (test for excess errors)
> > FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
> > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -Wc++-compat   scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> < FAIL: g++.dg/pr71488.C   (test for excess errors)
> < FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
> > FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments
> > FAIL: go.test/test/fixedbugs/issue27836.dir/Äfoo.go  -O -I. (test for excess errors)
> > FAIL: go.test/test/fixedbugs/issue27836.dir/Ämain.go  -O -I. (test for excess errors)
> 
> But they seem to be transient issues on my machine, as re-running them
> manually don't cause any issues.  Also, the tests themselves have
> nothing to do with floats so I don't see how they could be related.
> 
> Tested on x86-64 Linux.
> 
> I also ran the glibc testsuite (git sources) on x86-64 and this patch
> fixes:
> 
> -FAIL: math/test-double-lgamma
> -FAIL: math/test-double-log1p
> -FAIL: math/test-float-lgamma
> -FAIL: math/test-float-log1p
> -FAIL: math/test-float128-catan
> -FAIL: math/test-float128-catanh
> -FAIL: math/test-float128-lgamma
> -FAIL: math/test-float128-log
> -FAIL: math/test-float128-log1p
> -FAIL: math/test-float128-y0
> -FAIL: math/test-float128-y1
> -FAIL: math/test-float32-lgamma
> -FAIL: math/test-float32-log1p
> -FAIL: math/test-float32x-lgamma
> -FAIL: math/test-float32x-log1p
> -FAIL: math/test-float64-lgamma
> -FAIL: math/test-float64-log1p
> -FAIL: math/test-float64x-lgamma
> -FAIL: math/test-ldouble-lgamma
> 
> OK for trunk?
> 
> 	PR tree-optimization/107608
> 
> gcc/ChangeLog:
> 
> 	* range-op-float.cc (range_operator_float::fold_range): Avoid
> 	folding into INF when flag_trapping_math.
> 	* value-range.h (frange::known_isinf): Return false for possible NANs.

As a workaround this looks ok to me, but we need to figure out something
better for GCC 14.

Ok for trunk.

	Jakub


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
@ 2023-01-15 10:32 Aldy Hernandez
  2023-01-15 12:18 ` Jakub Jelinek
  0 siblings, 1 reply; 4+ messages in thread
From: Aldy Hernandez @ 2023-01-15 10:32 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Richard Biener, Andrew MacLeod, GCC patches, Aldy Hernandez

As discussed in the PR, for trapping math, do not fold overflowing
operations into +-INF as doing so could elide a trap.

There is a minor adjustment to known_isinf() where it was mistakenly
returning true for an [infinity U NAN], whereas it should only return
true when the range is exclusively +INF or -INF.  This is benign, as
there were no users of known_isinf up to now.

I had some testsuite issues with:

> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++14  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++17  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++20  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++98  scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
> FAIL: g++.dg/pr71488.C   (test for excess errors)
> FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
> FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -Wc++-compat   scan-sarif-file "text": "  int \\\\u6587\\\\u5b57\\\\u5316\\\\u3051 =
< FAIL: g++.dg/pr71488.C   (test for excess errors)
< FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin -flto-partition=none  line 23 p == 40
> FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments
> FAIL: go.test/test/fixedbugs/issue27836.dir/Äfoo.go  -O -I. (test for excess errors)
> FAIL: go.test/test/fixedbugs/issue27836.dir/Ämain.go  -O -I. (test for excess errors)

But they seem to be transient issues on my machine, as re-running them
manually don't cause any issues.  Also, the tests themselves have
nothing to do with floats so I don't see how they could be related.

Tested on x86-64 Linux.

I also ran the glibc testsuite (git sources) on x86-64 and this patch
fixes:

-FAIL: math/test-double-lgamma
-FAIL: math/test-double-log1p
-FAIL: math/test-float-lgamma
-FAIL: math/test-float-log1p
-FAIL: math/test-float128-catan
-FAIL: math/test-float128-catanh
-FAIL: math/test-float128-lgamma
-FAIL: math/test-float128-log
-FAIL: math/test-float128-log1p
-FAIL: math/test-float128-y0
-FAIL: math/test-float128-y1
-FAIL: math/test-float32-lgamma
-FAIL: math/test-float32-log1p
-FAIL: math/test-float32x-lgamma
-FAIL: math/test-float32x-log1p
-FAIL: math/test-float64-lgamma
-FAIL: math/test-float64-log1p
-FAIL: math/test-float64x-lgamma
-FAIL: math/test-ldouble-lgamma

OK for trunk?

	PR tree-optimization/107608

gcc/ChangeLog:

	* range-op-float.cc (range_operator_float::fold_range): Avoid
	folding into INF when flag_trapping_math.
	* value-range.h (frange::known_isinf): Return false for possible NANs.
---
 gcc/range-op-float.cc | 21 +++++++++++++++++++++
 gcc/value-range.h     |  1 +
 2 files changed, 22 insertions(+)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 986a3896a4f..74ac4658378 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -91,6 +91,27 @@ range_operator_float::fold_range (frange &r, tree type,
   else
     r.clear_nan ();
 
+  // If the result has overflowed and flag_trapping_math, folding this
+  // operation could elide an overflow or division by zero exception.
+  // Avoid returning a singleton +-INF, to keep the propagators (DOM
+  // and substitute_and_fold_engine) from folding.  See PR107608.
+  if (flag_trapping_math
+      && MODE_HAS_INFINITIES (TYPE_MODE (type))
+      && r.known_isinf () && !op1.known_isinf () && !op2.known_isinf ())
+    {
+      REAL_VALUE_TYPE inf = r.lower_bound ();
+      if (real_isneg (&inf))
+	{
+	  REAL_VALUE_TYPE min = real_min_representable (type);
+	  r.set (type, inf, min);
+	}
+      else
+	{
+	  REAL_VALUE_TYPE max = real_max_representable (type);
+	  r.set (type, max, inf);
+	}
+    }
+
   return true;
 }
 
diff --git a/gcc/value-range.h b/gcc/value-range.h
index ea50ed3e64a..f4ac73b499f 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -1300,6 +1300,7 @@ inline bool
 frange::known_isinf () const
 {
   return (m_kind == VR_RANGE
+	  && !maybe_isnan ()
 	  && real_identical (&m_min, &m_max)
 	  && real_isinf (&m_min));
 }
-- 
2.39.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-01-15 16:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-15 10:27 [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math Aldy Hernandez
2023-01-15 10:32 Aldy Hernandez
2023-01-15 12:18 ` Jakub Jelinek
2023-01-15 16:53   ` Aldy Hernandez

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