Re: [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
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 u6587u5b57u5316u3051 = FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++17 scan-sarif-file "text": " int u6587u5b57u5316u3051 = FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++20 scan-sarif-file "text": " int u6587u5b57u5316u3051 = FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++98 scan-sarif-file "text": " int u6587u5b57u5316u3051 = 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 u6587u5b57u5316u3051 = < 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
Re: [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
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 u6587u5b57u5316u3051 = > > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++17 > > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++20 > > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++98 > > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > > 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 u6587u5b57u5316u3051 = > < 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
[PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
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 u6587u5b57u5316u3051 = > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++17 > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++20 > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++98 > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > 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 u6587u5b57u5316u3051 = < 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 , 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 ()) + { + 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 (_min, _max) && real_isinf (_min)); } -- 2.39.0
[PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
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 u6587u5b57u5316u3051 = > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++17 > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++20 > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > FAIL: c-c++-common/diagnostic-format-sarif-file-4.c -std=gnu++98 > scan-sarif-file "text": " int u6587u5b57u5316u3051 = > 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 u6587u5b57u5316u3051 = < 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 , 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 ()) + { + 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 (_min, _max) && real_isinf (_min)); } -- 2.39.0