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
