[Bug tree-optimization/108819] [12/13 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu: tree check: expected ssa_name, have integer_cst in number_of_ite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108819 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:32b5875c911f80d551d006d7473e6f1f8705857a commit r13-6132-g32b5875c911f80d551d006d7473e6f1f8705857a Author: Jakub Jelinek Date: Sat Feb 18 12:40:49 2023 +0100 reassoc: Fold some statements [PR108819] This spot in update_ops can replace one or both of the assign operands with constants, creating 1 & 1 and similar expressions which can confuse later passes until they are folded. Rather than folding both constants by hand and also handling swapping of operands for commutative ops if the first one is constant and second one is not, the following patch just uses fold_stmt_inplace to do that. I think we shouldn't fold more than the single statement because that could screw up the rest of the pass, we'd have to mark all those with uids, visited and the like. 2023-02-18 Jakub Jelinek PR tree-optimization/108819 * tree-ssa-reassoc.cc (update_ops): Fold new stmt in place. * gcc.dg/pr108819.c: New test.
[Bug tree-optimization/108819] [12/13 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu: tree check: expected ssa_name, have integer_cst in number_of_ite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108819 --- Comment #4 from Jakub Jelinek --- (In reply to Richard Biener from comment #3) > --- a/gcc/tree-ssa-reassoc.cc > +++ b/gcc/tree-ssa-reassoc.cc > @@ -2950,6 +2950,9 @@ update_range_test (struct range_entry *range, struct > range_entry *otherrange, > } >if (stmt == NULL) > gcc_checking_assert (tem == op); > + /* When range->exp is a constant, we can use it as-is. */ > + else if (is_gimple_min_invariant (tem)) > +; >/* In rare cases range->exp can be equal to lhs of stmt. > In that case we have to insert after the stmt rather then before > it. If stmt is a PHI, insert it at the start of the basic block. */ That would make things worse, not better (i.e. constants could appear more often and we could trigger these problems more often), no? forwprop/ccp etc. should optimize it later... I wonder if we just can't do: --- gcc/tree-ssa-reassoc.cc.jj 2023-02-16 10:41:11.0 +0100 +++ gcc/tree-ssa-reassoc.cc 2023-02-17 17:43:52.169452832 +0100 @@ -4687,6 +4687,8 @@ update_ops (tree var, enum tree_code cod gimple_set_uid (g, gimple_uid (stmt)); gimple_set_visited (g, true); gsi_insert_before (, g, GSI_SAME_STMT); + gimple_stmt_iterator gsi2 = gsi_for_stmt (g); + fold_stmt_inplace (); } return var; } or if the in-place folding wouldn't be appropriate, at least fold it by hand if both arguments are constants. Though, there is also the case of commutative ops and just the first one turned into constant etc.
[Bug tree-optimization/108819] [12/13 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu: tree check: expected ssa_name, have integer_cst in number_of_ite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108819 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Richard Biener --- I have a patch to make niter analysis more defensive, the 1 & 1 is introduced by reassoc: @@ -30,8 +54,8 @@ [local count: 114863530]: _20 = a.0_1 == 0; _21 = a.0_1 > 0; - _22 = _20 & _21; - if (_22 != 0) + _7 = 1 & 1; + if (_7 != 0) where update_range_test gets a '1' as result and forces that to an SSA name and things go downhill from that. With diff --git a/gcc/tree-ssa-reassoc.cc b/gcc/tree-ssa-reassoc.cc index f163612f140..c2b30a03a9d 100644 --- a/gcc/tree-ssa-reassoc.cc +++ b/gcc/tree-ssa-reassoc.cc @@ -2950,6 +2950,9 @@ update_range_test (struct range_entry *range, struct range_entry *otherrange, } if (stmt == NULL) gcc_checking_assert (tem == op); + /* When range->exp is a constant, we can use it as-is. */ + else if (is_gimple_min_invariant (tem)) +; /* In rare cases range->exp can be equal to lhs of stmt. In that case we have to insert after the stmt rather then before it. If stmt is a PHI, insert it at the start of the basic block. */ this is resolved (but we still get the intermediate 1 & 1 created). Jakub, you know this code more(?), can you see whether there's a better place to handle this? I'm testing the niter fortification.
[Bug tree-optimization/108819] [12/13 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu: tree check: expected ssa_name, have integer_cst in number_of_ite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108819 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 --- Comment #2 from Richard Biener --- Not exactly "wrong", but yes, passes don't expect this. I will have a look.
[Bug tree-optimization/108819] [12/13 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu: tree check: expected ssa_name, have integer_cst in number_of_ite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108819 Andrew Pinski changed: What|Removed |Added Target Milestone|13.0|12.3 Status|UNCONFIRMED |NEW Summary|[13 Regression] ICE on |[12/13 Regression] ICE on |valid code at -O1 with |valid code at -O1 with |"-fno-tree-ccp |"-fno-tree-ccp |-fno-tree-forwprop" on |-fno-tree-forwprop" on |x86_64-linux-gnu: tree |x86_64-linux-gnu: tree |check: expected ssa_name, |check: expected ssa_name, |have integer_cst in |have integer_cst in |number_of_iterations_cltz, |number_of_iterations_cltz, |at |at |tree-ssa-loop-niter.cc:2394 |tree-ssa-loop-niter.cc:2394 Last reconfirmed||2023-02-16 Known to work||11.1.0, 11.3.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- _7 = 1 & 1; That I think is wrong but I think the problem is before ivcanon and it was latent in GCC 12 even. reassoc1 produces: [local count: 114863530]: _20 = a.0_1 == 0; _21 = a.0_1 > 0; _7 = 1 & 1; if (_7 != 0) goto ; [89.30%] else goto ; [10.70%] From: [local count: 114863530]: _20 = a.0_1 == 0; _21 = a.0_1 > 0; _22 = _20 & _21; if (_22 != 0) goto ; [89.30%] else goto ; [10.70%] All it has: Optimizing range tests a.0_1 -[, 0] and +[, 0] and +[0, 0] into 0 GCC 11 looks ok though: From: a.0_1 = a; if (a.0_1 <= 0) goto ; [20.45%] else goto ; [79.55%] [local count: 114863530]: _20 = a.0_1 == 0; _21 = a.0_1 > 0; _22 = _20 & _21; if (_22 != 0) goto ; [89.30%] else goto ; [10.70%] to: a.0_1 = a; _20 = a.0_1 == 0; _16 = 0; _21 = a.0_1 > 0; _7 = 1 & _16; if (_7 != 0) goto ; [89.30%] else goto ; [10.70%] So I am going to declare this as a latent bug (which the verifiers don't catch either ...).
