From: Aldy Hernandez <aldyh@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Richard Biener <richard.guenther@gmail.com>,
Andrew MacLeod <amacleod@redhat.com>,
GCC patches <gcc-patches@gcc.gnu.org>,
Aldy Hernandez <aldyh@redhat.com>
Subject: [PATCH] [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math.
Date: Sun, 15 Jan 2023 11:27:38 +0100 [thread overview]
Message-ID: <20230115102738.19101-1-aldyh@redhat.com> (raw)
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
next reply other threads:[~2023-01-15 10:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-15 10:27 Aldy Hernandez [this message]
2023-01-15 10:32 Aldy Hernandez
2023-01-15 12:18 ` Jakub Jelinek
2023-01-15 16:53 ` Aldy Hernandez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230115102738.19101-1-aldyh@redhat.com \
--to=aldyh@redhat.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).