gcc 6 and 7 ICE when compiling the following reduced snippet at -O3 (or -Ofast) w/ -g: int d0, sj, v0, rp, zi; void zn(void) { if (v0 != 0) { int *js, *r3; int pm, gc; for (gc = 0; gc < 1; ++gc) { sj = 1; while (sj != 0) ; } r3 = ± *js = &gc; ka: for (d0 = 0; d0 < 2; ++d0) { d0 = zi; if (zi) for (pm = 2; pm != 0; --pm) ; } while (*r3 != 0) { while (pm) ; ++r3; } } rp = 0; goto ka; } % gcc-7.0.0-alpha20160501 -c -O3 -g fngq6pkt.c fngq6pkt.c: In function 'zn': fngq6pkt.c:18:11: warning: assignment makes integer from pointer without a cast [-Wint-conversion] *js = &gc; ^ fngq6pkt.c:4:1: error: definition in block 9 does not dominate use in block 12 zn(void) ^~ for SSA_NAME: pm.7_34 in statement: # DEBUG pm => pm.7_34 fngq6pkt.c:4:1: internal compiler error: verify_ssa failed
Started with r228599.
This is tree_unswitch_outer_loop -> hoist_guard not resetting debug stmts that have some uses of SSA_NAMEs defined in the inner loop. But the transformation is really weird. We have: loop7================== bb10 | v loop2 ============= />bb8 | inv test | / | | | something | \ | \ | v v \ | bb7 + | | | +---+ | loop2 end ========= | v bb13 DEBUG pm = defined_in_something And we move the inv test to bb 10, with one edge going to loop2, and the other to bb13 (newly added edge). If I understand the cfg right though, we've thus changed an endless loop (if inv test is false, bb8 not really having any side-effects just jumped to bb7 and back to bb8 forever) into no loop, and in addition the newly added edge from bb10 to bb13 of course means any SSA_NAMEs defined in loop2 can't be used.
Jacub, Here is a simple fix - do not take into consideration edges destination of which is loop latch block, i.e. loop is endless: diff --git a/gcc/tree-ssa-loop-unswitch.c b/gcc/tree-ssa-loop-unswitch.c index dd6fd01..7de5fba 100644 --- a/gcc/tree-ssa-loop-unswitch.c +++ b/gcc/tree-ssa-loop-unswitch.c @@ -532,6 +532,12 @@ find_loop_guard (struct loop *loop) guard_edge->src->index, guard_edge->dest->index); return NULL; } + if (guard_edge->dest == loop->latch) + { + if (dump_file && (dump_flags & TDF_DETAILS)) + fprintf(dump_file,"Guard edge destination is loop latch!\n"); + return NULL; + } if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, Is it OK for you?
(In reply to Yuri Rumyantsev from comment #3) > Here is a simple fix - do not take into consideration edges destination of > which is loop latch block, i.e. loop is endless: > diff --git a/gcc/tree-ssa-loop-unswitch.c b/gcc/tree-ssa-loop-unswitch.c > index dd6fd01..7de5fba 100644 > --- a/gcc/tree-ssa-loop-unswitch.c > +++ b/gcc/tree-ssa-loop-unswitch.c > @@ -532,6 +532,12 @@ find_loop_guard (struct loop *loop) > guard_edge->src->index, guard_edge->dest->index); > return NULL; > } > + if (guard_edge->dest == loop->latch) > + { > + if (dump_file && (dump_flags & TDF_DETAILS)) > + fprintf(dump_file,"Guard edge destination is loop latch!\n"); Formatting - missing space before (. > + return NULL; > + } > > if (dump_file && (dump_flags & TDF_DETAILS)) > fprintf (dump_file, > > Is it OK for you? Richard knows this code much better than I do, so I'll defer to him. That said, is there any guarantee that for non-endless loop we won't run into the debug stmt issue? For normal non-debug uses of something set inside of the loop there would need to be a PHI on the exit block if it is reachable from outside of the loop too, the question is if it is possible even in the non-endless case that the exit block will be only reachable from within the loop. If yes, even normal SSA_NAME uses, not just in debug stmts, could be a problem.
Author: ienkovich Date: Fri May 6 12:07:25 2016 New Revision: 235962 URL: https://gcc.gnu.org/viewcvs?rev=235962&root=gcc&view=rev Log: gcc/ 2016-05-06 Yuri Rumyantsev <ysrumyan@gmail.com> PR debug/70935 * tree-ssa-loop-unswitch.c (find_loop_guard): Reject guard edge with loop latch destination. gcc/testsuite/ 2016-05-06 Yuri Rumyantsev <ysrumyan@gmail.com> PR debug/70935 * gcc.dg/torture/pr70935.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr70935.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-unswitch.c
Author: ienkovich Date: Tue May 10 14:26:37 2016 New Revision: 236081 URL: https://gcc.gnu.org/viewcvs?rev=236081&root=gcc&view=rev Log: gcc/ 2016-05-10 Yuri Rumyantsev <ysrumyan@gmail.com> Backport from mainline r235962. 2016-05-06 Yuri Rumyantsev <ysrumyan@gmail.com> PR debug/70935 * tree-ssa-loop-unswitch.c (find_loop_guard): Reject guard edge with loop latch destination. gcc/testsuite/ 2016-05-10 Yuri Rumyantsev <ysrumyan@gmail.com> Backport from mainline r235962. 2016-05-06 Yuri Rumyantsev <ysrumyan@gmail.com> PR debug/70935 * gcc.dg/torture/pr70935.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr70935.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-loop-unswitch.c
Can this PR be closed as RESOLVED FIXED now, or are there still parts missing?
Fixed