https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- I can reproduce on a stage2 compiler. I've narrowed it down to: -O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1 -fdisable-tree-thread2 -fdisable-tree-thread1 -fdbg-cnt=registered_jump_thread:543-544:550-555 Which is interesting because I've disabled both thread[12] and threadfull[12] which are the passes affected by the bisected culprit (r12-4790). All the threads come from ethread: $ grep Register.*jump gimplify.c.* gimplify.c.034t.ethread: [543] Registering jump thread: (687, 689) incoming edge; (689, 690) nocopy; gimplify.c.034t.ethread: [544] Registering jump thread: (688, 689) incoming edge; (689, 693) nocopy; gimplify.c.034t.ethread: [550] Registering jump thread: (776, 777) incoming edge; (777, 801) nocopy; gimplify.c.034t.ethread: [551] Registering jump thread: (779, 780) incoming edge; (780, 781) nocopy; gimplify.c.034t.ethread: [552] Registering jump thread: (780, 782) incoming edge; (782, 785) nocopy; gimplify.c.034t.ethread: [553] Registering jump thread: (784, 786) incoming edge; (786, 787) nocopy; gimplify.c.034t.ethread: [554] Registering jump thread: (785, 786) incoming edge; (786, 788) nocopy; gimplify.c.034t.ethread: [555] Registering jump thread: (804, 806) incoming edge; (806, 807) nocopy; ...which was not affected by the commit, and which is a rather simple threading pass with no IL changes and no full resolving ranger mode. If I disable DOM it goes away, so *maybe* these ethreads cause DOM to perform an optimization that triggers the ICE. Damn it. These bugs are getting trickier and trickier. Where are the simple 5 liners I could fix in no time flat? :)
