* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
@ 2020-11-05 7:40 ` rguenth at gcc dot gnu.org
2020-11-05 8:37 ` marxin at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-05 7:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
CC| |aldyh at gcc dot gnu.org
Target Milestone|--- |11.0
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
2020-11-05 7:40 ` [Bug tree-optimization/97721] " rguenth at gcc dot gnu.org
@ 2020-11-05 8:37 ` marxin at gcc dot gnu.org
2020-11-05 9:18 ` aldyh at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-11-05 8:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com,
| |marxin at gcc dot gnu.org
Ever confirmed|0 |1
Keywords| |ice-on-valid-code
Last reconfirmed| |2020-11-05
Known to work| |10.2.0
Known to fail| |11.0
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r11-4135-ge864d395b4e862ce.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
2020-11-05 7:40 ` [Bug tree-optimization/97721] " rguenth at gcc dot gnu.org
2020-11-05 8:37 ` marxin at gcc dot gnu.org
@ 2020-11-05 9:18 ` aldyh at gcc dot gnu.org
2020-11-05 9:24 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2020-11-05 9:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
The ranger is analyzing a statement with an integer overflow, and creating a
non-legacy range that is invalid:
(gdb) p debug(stmt)
if (_1 != -1(OVF))
(gdb) p debug(op2_range)
int [-1(OVF), -1(OVF)]
(gdb) p op2_range.legacy_mode_p()
$8 = false
Legacy ranges allow TREE_OVERFLOW to creep in, as the verifier allows symbolics
and other end points that are not comparable at compile time (cmp == -2 below):
case VR_ANTI_RANGE:
case VR_RANGE:
{
gcc_assert (m_num_ranges == 1);
int cmp = compare_values (tree_lower_bound (0), tree_upper_bound (0));
gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
return;
}
However, we're a bit more strict in irange. We don't allow un-comparable
endpoints and TREE_OVERFLOW integers are such.
I'm not sure where to fix this.
Is the original statement valid gimple? Richard has mentioned that any time
there's a TREE_OVERFLOW in the IL, it's a sign of a bug. If the IL is wrong,
we should tackle the source problem.
If the IL is ocrrect, then perhaps we could drop OVF at range creation.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (2 preceding siblings ...)
2020-11-05 9:18 ` aldyh at gcc dot gnu.org
@ 2020-11-05 9:24 ` jakub at gcc dot gnu.org
2020-11-05 9:27 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-05 9:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems ivopts changes:
@@ -24,7 +24,7 @@ z6 (char * tw)
<bb 3> [local count: 955630225]:
# ot.1_12 = PHI <_1(6), ot.1_11(5)>
_1 = ot.1_12 + -1;
- if (_1 >= 0)
+ if (_1 != -1(OVF))
goto <bb 6>; [89.00%]
else
goto <bb 9>; [11.00%]
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (3 preceding siblings ...)
2020-11-05 9:24 ` jakub at gcc dot gnu.org
@ 2020-11-05 9:27 ` jakub at gcc dot gnu.org
2020-11-05 10:20 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-05 9:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We have drop_tree_overflow, so perhaps ivopts could use if (TREE_OVERFLOW_P
(whatever)) whatever = drop_tree_overflow (whatever); somewhere.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (4 preceding siblings ...)
2020-11-05 9:27 ` jakub at gcc dot gnu.org
@ 2020-11-05 10:20 ` rguenth at gcc dot gnu.org
2020-11-05 11:36 ` aldyh at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-05 10:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #2)
> The ranger is analyzing a statement with an integer overflow, and creating a
> non-legacy range that is invalid:
>
> (gdb) p debug(stmt)
> if (_1 != -1(OVF))
>
> (gdb) p debug(op2_range)
> int [-1(OVF), -1(OVF)]
>
> (gdb) p op2_range.legacy_mode_p()
> $8 = false
>
> Legacy ranges allow TREE_OVERFLOW to creep in, as the verifier allows
> symbolics and other end points that are not comparable at compile time (cmp
> == -2 below):
>
> case VR_ANTI_RANGE:
> case VR_RANGE:
> {
> gcc_assert (m_num_ranges == 1);
> int cmp = compare_values (tree_lower_bound (0), tree_upper_bound (0));
> gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
> return;
> }
>
> However, we're a bit more strict in irange. We don't allow un-comparable
> endpoints and TREE_OVERFLOW integers are such.
>
> I'm not sure where to fix this.
>
> Is the original statement valid gimple? Richard has mentioned that any time
> there's a TREE_OVERFLOW in the IL, it's a sign of a bug. If the IL is
> wrong, we should tackle the source problem.
>
> If the IL is ocrrect, then perhaps we could drop OVF at range creation.
Yes, the IL is "correct", just inefficent and possibly confusing to passes.
The OVF flag on INTEGER_CST have _no_ semantic meaning in the IL so making
them "invalid" in ranger doesn't make sense.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (5 preceding siblings ...)
2020-11-05 10:20 ` rguenth at gcc dot gnu.org
@ 2020-11-05 11:36 ` aldyh at gcc dot gnu.org
2020-11-05 11:41 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2020-11-05 11:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Aldy Hernandez from comment #2)
> Yes, the IL is "correct", just inefficent and possibly confusing to passes.
>
> The OVF flag on INTEGER_CST have _no_ semantic meaning in the IL so making
> them "invalid" in ranger doesn't make sense.
The ranger treating them invalid was a precaution since the conversion to trees
brought the use of compare_values_warnv(), which claims overflowed values
cannot be compared. But if in fact they can be compared, then perhaps
compare_values_warnv is wrong in claiming the opposite:
/* We cannot say anything more for non-constants. */
if (!cst1 || !cst2)
return -2;
if (!POINTER_TYPE_P (TREE_TYPE (val1)))
{
/* We cannot compare overflowed values. */
if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
return -2;
What do you think?
It would seem to me that removing this restriction would work, especially since
tree_int_cst_compare, which this function uses, just degrades to wide ints,
which don't care about TREE_OVERFLOW.
[untested]
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index e00c034fee3..8702ad1ae8d 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -609,10 +609,6 @@ compare_values_warnv (tree val1, tree val2, bool
*strict_overflow_p)
if (!POINTER_TYPE_P (TREE_TYPE (val1)))
{
- /* We cannot compare overflowed values. */
- if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
- return -2;
-
if (TREE_CODE (val1) == INTEGER_CST
&& TREE_CODE (val2) == INTEGER_CST)
return tree_int_cst_compare (val1, val2);
@@ -635,13 +631,7 @@ compare_values_warnv (tree val1, tree val2, bool
*strict_overflow_p)
else
{
if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
- {
- /* We cannot compare overflowed values. */
- if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
- return -2;
-
- return tree_int_cst_compare (val1, val2);
- }
+ return tree_int_cst_compare (val1, val2);
/* First see if VAL1 and VAL2 are not the same. */
if (operand_equal_p (val1, val2, 0))
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (6 preceding siblings ...)
2020-11-05 11:36 ` aldyh at gcc dot gnu.org
@ 2020-11-05 11:41 ` jakub at gcc dot gnu.org
2020-11-05 11:49 ` aldyh at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-05 11:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or when
folding some expression. It just doesn't belong into the GIMPLE IL.
So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
somewhere in the IL not to set the range to that constant, but to
drop_tree_overflow of it.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (7 preceding siblings ...)
2020-11-05 11:41 ` jakub at gcc dot gnu.org
@ 2020-11-05 11:49 ` aldyh at gcc dot gnu.org
2020-11-05 12:13 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2020-11-05 11:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> when folding some expression. It just doesn't belong into the GIMPLE IL.
> So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
> somewhere in the IL not to set the range to that constant, but to
> drop_tree_overflow of it.
That's certainly the easiest path for us. We could drop_overflow in
get_tree_range while creating said ranges, and then no other changes to the
ranger are needed.
However, I wonder if compare_values_warnv is being unnecessarily restrictive.
For example, here, we bail on overflow, even though tree_int_cst_compare,
through its use of wi::cmps, is perfectly capable of comparing these integers:
if (!POINTER_TYPE_P (TREE_TYPE (val1)))
{
/* We cannot compare overflowed values. */
if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
return -2;
if (TREE_CODE (val1) == INTEGER_CST
&& TREE_CODE (val2) == INTEGER_CST)
return tree_int_cst_compare (val1, val2);
as well as here:
if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
{
/* We cannot compare overflowed values. */
if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
return -2;
return tree_int_cst_compare (val1, val2);
}
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (8 preceding siblings ...)
2020-11-05 11:49 ` aldyh at gcc dot gnu.org
@ 2020-11-05 12:13 ` rguenth at gcc dot gnu.org
2020-11-05 13:12 ` aldyh at redhat dot com
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-05 12:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> > when folding some expression. It just doesn't belong into the GIMPLE IL.
> > So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
> > somewhere in the IL not to set the range to that constant, but to
> > drop_tree_overflow of it.
>
> That's certainly the easiest path for us. We could drop_overflow in
> get_tree_range while creating said ranges, and then no other changes to the
> ranger are needed.
>
> However, I wonder if compare_values_warnv is being unnecessarily
> restrictive. For example, here, we bail on overflow, even though
> tree_int_cst_compare, through its use of wi::cmps, is perfectly capable of
> comparing these integers:
>
> if (!POINTER_TYPE_P (TREE_TYPE (val1)))
> {
> /* We cannot compare overflowed values. */
> if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> return -2;
>
> if (TREE_CODE (val1) == INTEGER_CST
> && TREE_CODE (val2) == INTEGER_CST)
> return tree_int_cst_compare (val1, val2);
>
> as well as here:
>
> if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> {
> /* We cannot compare overflowed values. */
> if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> return -2;
>
> return tree_int_cst_compare (val1, val2);
> }
VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
on some TREE_OVERFLOW bits therein. This might be all long history
but the above is probably because of that.
Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
of the IL for VRP purposes (as said, some passes are "confused" about
existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
internal processing - which, nowadays should use wide_int).
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (9 preceding siblings ...)
2020-11-05 12:13 ` rguenth at gcc dot gnu.org
@ 2020-11-05 13:12 ` aldyh at redhat dot com
2020-11-05 16:16 ` cvs-commit at gcc dot gnu.org
2020-11-05 16:19 ` aldyh at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at redhat dot com @ 2020-11-05 13:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #10 from Aldy Hernandez <aldyh at redhat dot com> ---
> > as well as here:
> >
> > if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> > {
> > /* We cannot compare overflowed values. */
> > if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> > return -2;
> >
> > return tree_int_cst_compare (val1, val2);
> > }
>
> VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
> on some TREE_OVERFLOW bits therein. This might be all long history
> but the above is probably because of that.
>
> Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
> of the IL for VRP purposes (as said, some passes are "confused" about
> existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
> internal processing - which, nowadays should use wide_int).
Ok, let's let sleeping dogs lie then. I'll drop the overflow will
building ranges.
Thanks for the explanation.
I'll commit the following if it passes tests.
Aldy
Drop overflow from constants while building ranges in ranger.
Sometimes overflow flag will leak into the IL. Drop them while
creating ranges.
gcc/ChangeLog:
PR tree-optimization/97721
* gimple-range.cc (get_tree_range): Drop overflow from constants.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97721.c: New test.
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index cf979845acf..6d351002830 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -165,6 +165,8 @@ get_tree_range (irange &r, tree expr)
switch (TREE_CODE (expr))
{
case INTEGER_CST:
+ if (TREE_OVERFLOW_P (expr))
+ expr = drop_tree_overflow (expr);
r.set (expr, expr);
return true;
diff --git a/gcc/testsuite/gcc.dg/pr97721.c b/gcc/testsuite/gcc.dg/pr97721.c
new file mode 100644
index 00000000000..c2a2848ba13
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97721.c
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-O -fno-tree-dominator-opts" }
+
+int ot;
+
+void
+z6 (char *tw)
+{
+ while (ot >= 0)
+ --ot;
+
+ __builtin_strcpy (&tw[ot], tw);
+}
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (10 preceding siblings ...)
2020-11-05 13:12 ` aldyh at redhat dot com
@ 2020-11-05 16:16 ` cvs-commit at gcc dot gnu.org
2020-11-05 16:19 ` aldyh at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-05 16:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:
https://gcc.gnu.org/g:4ef0f1e90f1795b1f2d5bba05ed299e8c7635fd4
commit r11-4743-g4ef0f1e90f1795b1f2d5bba05ed299e8c7635fd4
Author: Aldy Hernandez <aldyh@redhat.com>
Date: Thu Nov 5 12:40:51 2020 +0100
Drop overflow from constants while building ranges in ranger.
Sometimes the overflow flag will leak into the IL. Drop it while
creating ranges.
There are various places we could plug this. This patch just plugs things
at get_tree_range which is the entry point for ranges from tree
expressions.
It fixes the PR, and probably fixes the ranger entirely, but we may need
to revisit this.
For example, I looked to see if there were other places that created
ranges with TREE_OVERFLOW set, and there are various. For example,
the following code pattern appears multiple times in vr-values.c:
else if (is_gimple_min_invariant (op0))
vr0.set (op0);
This can pick up TREE_OVERFLOW from the IL if present. However, the
ranger won't see them so we're good.
At some point we should audit all this. Or perhaps just nuke all
TREE_OVERFLOW's at irange::set.
For now, this will do.
gcc/ChangeLog:
PR tree-optimization/97721
* gimple-range.cc (get_tree_range): Drop overflow from constants.
gcc/testsuite/ChangeLog:
* gcc.dg/pr97721.c: New test.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361
2020-11-05 2:37 [Bug tree-optimization/97721] New: [11 Regression] ICE in verify_range, at value-range.cc:361 asolokha at gmx dot com
` (11 preceding siblings ...)
2020-11-05 16:16 ` cvs-commit at gcc dot gnu.org
@ 2020-11-05 16:19 ` aldyh at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: aldyh at gcc dot gnu.org @ 2020-11-05 16:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
fixed
^ permalink raw reply [flat|nested] 14+ messages in thread