[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Andrew Pinski changed: What|Removed |Added CC||vsevolod.livinskiy at gmail dot co ||m --- Comment #15 from Andrew Pinski --- *** Bug 108668 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #13 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:e261fcefb71e1270673f0457fcc73711f13d3079 commit r13-5696-ge261fcefb71e1270673f0457fcc73711f13d3079 Author: Aldy Hernandez Date: Thu Feb 2 18:08:44 2023 +0100 irange: Compare nonzero bits in irange with widest_int [PR108639] The problem here is we are trying to compare two ranges with different precisions and the == operator in wide_int is complaining. Interestingly, the problem is not the nonzero bits, but the fact that the entire ranges have different precisions. The reason we don't ICE when comparing the sub-ranges, is because the code in irange::operator== works on trees, and tree_int_cst_equal is promoting the comparison to a widest int: if (TREE_CODE (t1) == INTEGER_CST && TREE_CODE (t2) == INTEGER_CST && wi::to_widest (t1) == wi::to_widest (t2)) return 1; This is why we don't see the ICE until the nonzero bits comparison is done on wide ints. I think we should maintain the current equality behavior, and follow suit in the nonzero bit comparison. I have also fixed the legacy equality code, even though technically nonzero bits shouldn't appear in legacy. But better safe than sorry. PR tree-optimization/108639 gcc/ChangeLog: * value-range.cc (irange::legacy_equal_p): Compare nonzero bits as widest_int. (irange::operator==): Same.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #12 from Aldy Hernandez --- Yeah, I've been mulling around the idea of removing the type from storage of both irange and frange. It seems we need it for setting a type (setting the endpoints for varying, querying HONOR_NANS, HONOR_INFINITIES,e tc), but not in the storage itself. Something to keep in mind when moving to wide_ints. It does seem we need to keep the sign and precision somewhere. The precision lives in the wide-int, but the sign bit still needs storage??
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #11 from Richard Biener --- Yes, they should compare equal. Integer constant ranges do not need a type. Not even FP constant ranges. Symbolic ranges need a type, but then the endpoints in their symbolic form have one (and those might even differ).
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #10 from Jakub Jelinek ---
Ok then.
I won't test my patch then, the testcases from it were:
--- gcc/testsuite/gcc.c-torture/compile/pr108638.c.jj 2022-11-21
10:04:00.210677046 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr108638.c 2023-02-02
16:51:06.082371450 +0100
@@ -0,0 +1,12 @@
+/* PR tree-optimization/108638 */
+
+long long a;
+int b;
+
+void
+foo (void)
+{
+ for (a = 0; a < __SIZEOF_LONG_LONG__ * __CHAR_BIT__; a++)
+if (b)
+ b |= a << a;
+}
--- gcc/testsuite/gcc.c-torture/compile/pr108639.c.jj 2023-02-02
16:26:44.113600462 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr108639.c 2023-02-02
16:26:23.309902211 +0100
@@ -0,0 +1,11 @@
+/* PR tree-optimization/108639 */
+
+long long a;
+
+int
+main ()
+{
+ a = a ? 0 || 0 % 0 : 0;
+ a = a << a;
+ return 0;
+}
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #9 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #8) > (In reply to Aldy Hernandez from comment #5) > > (In reply to Jakub Jelinek from comment #3) > > > Created attachment 54391 [details] > > > gcc13-pr108639.patch > > > > > > Untested fix. > > > > I think the problem is more fundamental than that. The equality operator > > for irange is not ICEing for the sub-range comparison (which also have > > different precision), but is dying in the nonzero mask comparison. > > Well, that is obvious, because for the actual range boundaries you compare > trees, not wide_ints. And operand_equal_p does allow comparing of trees > with different types. > It in that case calls tree_int_cst_equal. But when you switch the > boundaries from trees to wide_ints, they will ICE again as well. > > I think for the operator==, the important question is, shall ranges with > same values but non-compatible types compare > 1) equal > 2) non-equal > 3) be an ICE (e.g. gcc_checking_assert) > The current state is 3) without the assert and my patch was trying to fix > the caller. 3) is not a desired result for sure. I think 1) is our desired outcome... I initially considered 2) as desirable as we could simply check the types before doing any other work. As I thought about it tho, I can't think of any good reason why we would want them to be unequal. If they compare equal this way (ignoring type), then performing a cast on either of them to the same type as the other would also compare equal... its symmetrical so that actually makes them equal in my book.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #8 from Jakub Jelinek --- (In reply to Aldy Hernandez from comment #5) > (In reply to Jakub Jelinek from comment #3) > > Created attachment 54391 [details] > > gcc13-pr108639.patch > > > > Untested fix. > > I think the problem is more fundamental than that. The equality operator > for irange is not ICEing for the sub-range comparison (which also have > different precision), but is dying in the nonzero mask comparison. Well, that is obvious, because for the actual range boundaries you compare trees, not wide_ints. And operand_equal_p does allow comparing of trees with different types. It in that case calls tree_int_cst_equal. But when you switch the boundaries from trees to wide_ints, they will ICE again as well. I think for the operator==, the important question is, shall ranges with same values but non-compatible types compare 1) equal 2) non-equal 3) be an ICE (e.g. gcc_checking_assert) The current state is 3) without the assert and my patch was trying to fix the caller. Your patch is changing it to 1), in that case no change would be needed in the particular lh == rh user, but are we sure that everywhere where non-compatible types could appear we don't imply from operator== returning true that the types are actually the same? If we did 2) e.g. by adding a types_compatible_p (type (), b.type ()) check, then we'd need to change this lh == rh user too, because for the shifts we really just care about values and not the exact types which can differ.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #7 from Aldy Hernandez --- Jakub, take a look and see if you agree. I've fired off some tests.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #6 from Aldy Hernandez --- Created attachment 54393 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54393=edit untested patch for irange::operator==
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #5 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #3) > Created attachment 54391 [details] > gcc13-pr108639.patch > > Untested fix. I think the problem is more fundamental than that. The equality operator for irange is not ICEing for the sub-range comparison (which also have different precision), but is dying in the nonzero mask comparison.
[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Jakub Jelinek changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from Jakub Jelinek --- *** Bug 108638 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 54391 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54391=edit gcc13-pr108639.patch Untested fix.
[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Jakub Jelinek changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Jakub Jelinek --- The problem is in 271 if (relation_equiv_p (rel) && lh == rh) We see # RANGE [irange] int [0, 1] NONZERO 0x1 # iftmp.0_6 = PHI <_10(3), 0(2)> # RANGE [irange] long int [0, 1] NONZERO 0x1 _3 = (long int) iftmp.0_6; # RANGE [irange] unsigned int [0, 1] NONZERO 0x1 _4 = (unsigned int) iftmp.0_6; # RANGE [irange] long int [-INF, +INF] NONZERO 0x3 _5 = _3 << _4; so lhs and rhs indeed have the same range, but unlike most binary operations, shifts/rotates have the same type between lhs and rhs1, but rhs2 can have different type. So, the lh == rh comparison ICEs because the wide_ints have different precision (but same values).
[Bug tree-optimization/108639] ]13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Jakub Jelinek changed: What|Removed |Added Version|unknown |13.0 Ever confirmed|0 |1 Priority|P3 |P1 CC||jakub at gcc dot gnu.org Summary|ICE on valid code at -O1|]13 Regression] ICE on |and above: in decompose, at |valid code at -O1 and |wide-int.h:984 |above: in decompose, at ||wide-int.h:984 since ||r13-5578 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Last reconfirmed||2023-02-02 --- Comment #1 from Jakub Jelinek --- Started with r13-5578-g809d661aff99ae0287baf4a52269425de62381e6
