[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri May  6 12:07:25 2016
New Revision: 235962

URL: https://gcc.gnu.org/viewcvs?rev=235962=gcc=rev
Log:
gcc/

2016-05-06  Yuri Rumyantsev  

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  

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

[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935

--- Comment #4 from Jakub Jelinek  ---
(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.

[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[ysrumyan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935

--- Comment #3 from Yuri Rumyantsev  ---
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?

[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||ienkovich at gcc dot gnu.org

[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935

--- Comment #2 from Jakub Jelinek  ---
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.

[Bug debug/70935] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-04
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.2
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r228599.