This appears to be a very recent regression. Compiler Explorer: https://godbolt.org/z/nv9dPa1Y7 [629] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++ --disable-werror --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230501 (experimental) (GCC) [630] % [630] % gcctk -O1 -ftree-vectorize small.c during GIMPLE pass: ch_vect small.c: In function ‘main’: small.c:2:5: internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 2 | int main() { | ^~~~ 0x822c59 check_loop_closed_ssa_def ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:645 0x11cfc34 check_loop_closed_ssa_bb ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:659 0x11d18be verify_loop_closed_ssa(bool, loop*) ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:695 0x11d18be verify_loop_closed_ssa(bool, loop*) ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:679 0xf243f9 execute_function_todo ../../gcc-trunk/gcc/passes.cc:2116 0xf24bfe execute_todo ../../gcc-trunk/gcc/passes.cc:2152 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. [631] % [631] % cat small.c int a, b, c, d, e; int main() { char f; while (a) { int g, h = 3; if (b) i: if (d) goto j; k: if (a) { j: if (!g) goto k; if (e) { while (e) e = f; h = 0; goto i; } if (!h) for (; g < 1; g++) ; g = ~((~c & h & c) ^ ~g); if (!g) for (; a < 1; a++) f++; } } return 0; }
Maybe r14-301-gf2d6beb7a4ddf18dd or r14-145-g2f4e45101dd812a6f (or r14-150-gf7b9258e0d4127c1f4 ).
Confirmed.
LC SSA is broken by unloop_loops (). That introduces BB 19 which is <bb 19> [count: 0]: f.8_13 = (unsigned char) f_19; _14 = f.8_13 + 1; f_38 = (char) _14; _16 = a_lsm.17_51 + 1; __builtin_unreachable (); but that's an exit from the loop and is missing LC PHI nodes for all of the SSA names used.
Started with r14-301-gf2d6beb7a4ddf1.
*** Bug 110123 has been marked as a duplicate of this bug. ***
*** Bug 110135 has been marked as a duplicate of this bug. ***
Another related and smaller reproducer: [514] % gcctk -O3 -fno-tree-loop-ivcanon small.c during GIMPLE pass: ch_vect small.c: In function ‘main’: small.c:3:5: internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647 3 | int main() { | ^~~~ 0x81089b check_loop_closed_ssa_def ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:647 0x1137d37 check_loop_closed_ssa_bb ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:672 0x1138116 verify_loop_closed_ssa(bool, loop*) ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:697 0x1138116 verify_loop_closed_ssa(bool, loop*) ../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:681 0xe9ff39 execute_function_todo ../../gcc-trunk/gcc/passes.cc:2116 0xea032b execute_todo ../../gcc-trunk/gcc/passes.cc:2152 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. [515] % [515] % cat small.c int a; unsigned c; int main() { L: if (c) for (; c < 2;) { int e; for (a = 0; a < 2; a++) { c++; while (e) goto L; } } return 0; }
An easy way would be to avoid unlooping if tree_ssa_loop_ch is executed in loop closed ssa (which happens from ch_vect pass). I wonder how hard would be however to get this right? I think this means to take the basic block we turn into unreachable and look on its predecessors that are in loop introducing new PHIs and renaming. This is bit involved to do by hand. So perhaps simply: rewrite_into_loop_closed_ssa (NULL, 0); in case we unlooped in loop closed ssa form (which is not that common). Would that be acceptable?
(In reply to Jan Hubicka from comment #8) > An easy way would be to avoid unlooping if tree_ssa_loop_ch is executed in > loop closed ssa (which happens from ch_vect pass). > > I wonder how hard would be however to get this right? > I think this means to take the basic block we turn into unreachable and look > on its predecessors that are in loop introducing new PHIs and renaming. > This is bit involved to do by hand. > > So perhaps simply: > rewrite_into_loop_closed_ssa (NULL, 0); > in case we unlooped in loop closed ssa form (which is not that common). > Would that be acceptable? Yes, we do that in other places as well.
> > So perhaps simply: > > rewrite_into_loop_closed_ssa (NULL, 0); > > in case we unlooped in loop closed ssa form (which is not that common). > > Would that be acceptable? > > Yes, we do that in other places as well. OK, I will test the fix. Thanks Honza
*** Bug 111389 has been marked as a duplicate of this bug. ***
*** Bug 112489 has been marked as a duplicate of this bug. ***
*** Bug 111678 has been marked as a duplicate of this bug. ***
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:8ff02df62935429d8956361cfdb897122492523d commit r14-6181-g8ff02df62935429d8956361cfdb897122492523d Author: Richard Biener <rguenther@suse.de> Date: Tue Dec 5 08:50:57 2023 +0100 tree-optimization/112856 - fix LC SSA after loop header copying When loop header copying unloops loops we have to possibly fixup LC SSA. I've take the opportunity to streamline the unloop_loops API, removing the use of a ivcanon local global variable. PR tree-optimization/109689 PR tree-optimization/112856 * cfgloopmanip.h (unloop_loops): Adjust API. * tree-ssa-loop-ivcanon.cc (unloop_loops): Take edges_to_remove as parameter. (canonicalize_induction_variables): Adjust. (tree_unroll_loops_completely): Likewise. * tree-ssa-loop-ch.cc (ch_base::copy_headers): Rewrite into LC SSA if we unlooped some loops and we are in LC SSA. * gcc.dg/torture/pr109689.c: New testcase. * gcc.dg/torture/pr112856.c: Likewise.
Fixed.