[Bug tree-optimization/66372] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #4 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
I think this is the same issue as I spotted in the larger testcase.

Looking at the cancelled jumps:

  trunk/foo.c.096t.dom1:  Cancelling jump thread: (6, 8) incoming edge;  (8,
13) joiner;  (13, 9) normal;
  trunk/foo.c.096t.dom1:  Cancelling jump thread: (7, 9) incoming edge;  (9,
13) joiner;  (13, 10) normal;

With r223448 reverted:

  reverted/small.c.096t.dom1:  Cancelling jump thread: (6, 8) incoming edge; 
(8, 13) joiner;  (13, 9) normal;
  reverted/small.c.096t.dom1:  Cancelling jump thread: (7, 9) incoming edge; 
(9, 13) joiner;  (13, 10) normal;
  reverted/small.c.096t.dom1:  Cancelling jump thread: (2, 3) incoming edge; 
(3, 4) joiner;  (4, 5) normal;

If we fail to cancel 2 --> 3 to 5, we will probably end up in trouble given the
other blocks we've threaded through:

  trunk/small.c.096t.dom1:  Threaded jump 6 --> 10 to 16
  trunk/small.c.096t.dom1:  Threaded jump 7 --> 10 to 16
  trunk/small.c.096t.dom1:  Threaded jump 15 --> 13 to 17
  trunk/small.c.096t.dom1:  Threaded jump 8 --> 13 to 17
  trunk/small.c.096t.dom1:  Threaded jump 3 --> 4 to 15
  trunk/small.c.096t.dom1:  Threaded jump 14 --> 13 to 16
  trunk/small.c.096t.dom1:  Threaded jump 9 --> 13 to 16

And taking a look at the path we're processing just before the ICE, it does
start (2, 3).