[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 --- Comment #10 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:dce4da51ab66c3abb84448326910cd42f6fe2499 commit r16-1027-gdce4da51ab66c3abb84448326910cd42f6fe2499 Author: Richard Biener Date: Fri May 30 14:11:47 2025 +0200 tree-optimization/120357 - ICE with early break vectorization When doing early break vectorization of a loop with a conditional reduction the epilog creation code is confused as to before which exit to insert the conditional reduction induction IV update. The following make sure this is done before the main IV exit. PR tree-optimization/120357 * tree-vect-loop.cc (vect_create_epilog_for_reduction): Create the conditional reduction induction IV increment before the main IV exit. * gcc.dg/vect/vect-early-break_136-pr120357.c: New testcase.
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 --- Comment #9 from Tamar Christina --- (In reply to Richard Biener from comment #8) > The following fixes this. I'm not 100% convinced but it does seem "obvious" > (but for the "peeled" case we seem to eventually create duplicate COND > reduction IVs? But possibly we reject this case anyhow). I'm testing this > now. > It looks obvious to me too and I guess I had just missed it during the removal of the explicit loop_exits. The duplicate reduction comes from that for the PEELED case we still have a separate BB for the main and "early" exit. For the PEELED case we treated all exits as being early but in the CFG they aren't. I think we could fix this by in slpeel_tree_duplicate_loop_to_edge_cfg when "peeled" point every exit, including the main one to the same block. Then in vectorizable_live_operations and friends we can remove the special casing for LOOP_VINFO_EARLY_BREAKS_VECT_PEELED since the codegening the first exit would cover all exits. Which would remove the duplicate reduction calculation.
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 --- Comment #8 from Richard Biener --- The following fixes this. I'm not 100% convinced but it does seem "obvious" (but for the "peeled" case we seem to eventually create duplicate COND reduction IVs? But possibly we reject this case anyhow). I'm testing this now. diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc index 4af510ff20c..cf5b9f3f979 100644 --- a/gcc/tree-vect-loop.cc +++ b/gcc/tree-vect-loop.cc @@ -6029,7 +6029,8 @@ vect_create_epilog_for_reduction (loop_vec_info loop_vinfo, /* Create an induction variable. */ gimple_stmt_iterator incr_gsi; bool insert_after; - vect_iv_increment_position (loop_exit, &incr_gsi, &insert_after); + vect_iv_increment_position (LOOP_VINFO_IV_EXIT (loop_vinfo), + &incr_gsi, &insert_after); create_iv (series_vect, PLUS_EXPR, vec_step, NULL_TREE, loop, &incr_gsi, insert_after, &indx_before_incr, &indx_after_incr);
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 --- Comment #7 from Tamar Christina --- (In reply to Richard Biener from comment #5) > Confirmed on trunk. I'll eventually have a look. Sorry I'm on holiday till Tuesday, I'm happy to take a look then if you prefer. I did not mean to dump my bugs on you.
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 Richard Biener changed: What|Removed |Added Target Milestone|14.3|14.4 --- Comment #6 from Richard Biener --- GCC 14.3 is being released, retargeting bugs to GCC 14.4.
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 Richard Biener changed: What|Removed |Added Target Milestone|16.0|14.3 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P2 --- Comment #5 from Richard Biener --- Confirmed on trunk. I'll eventually have a look.
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
Alex Coplan changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Summary|[15/16 Regression] ICE in |[14/15/16 Regression] ICE
|vect pass "error: |in vect "error: definition
|definition in block 9 does |in block 9 does not
|not dominate use in block |dominate use in block 3"
|3" since|with early break
|r15-6807-g68326d5d1a593d|
Keywords||ice-checking
--- Comment #4 from Alex Coplan ---
The following simplified testcase ICEs in the same way back to the introduction
of early break vectorization in GCC 14:
char a;
unsigned long long t[2][22];
int u[22];
void f(void) {
for (int v = 0; v < 22; v++)
for (_Bool w = 0; w < (u[v] < 0) + 1; w = 1)
a *= 0 != t[w][v];
}
So for AArch64, that's r14-6823-g1bcc07aeb47c0ed7eb50eac8a4e057d6336669ab, but
since that's the AArch64 introduction of the cbranch optab it would of course
be different for other targets.
Either way this shows the problem is independent of alignment peeling and
likely a generic early break vect issue.
Note that it's a checking ICE so needs --enable-checking=yes or compiling with
-fchecking.
