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).
