https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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.
