https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 30 Sep 2021, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 > > Aldy Hernandez <aldyh at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rguenth at gcc dot gnu.org > > --- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > A little -fdbg-cnt bisecting magic shows that the first jump thread causes > some > sort of reaction downstream in unrolljam: > > ./cc1 a.c -quiet -O3 -fno-tree-ch -fdbg-cnt=registered_jump_thread:1-1 > ***dbgcnt: lower limit 1 reached for registered_jump_thread.*** > ***dbgcnt: upper limit 1 reached for registered_jump_thread.*** > during GIMPLE pass: unrolljam > a.c: In function ‘b’: > a.c:5:6: internal compiler error: Segmentation fault > > So it's the first threading path that is causing an issue. Setting a > breakpoint at path registering yields this: > > Breakpoint 5, jt_path_registry::register_jump_thread (this=0x391f150, Python > Exception <class 'gdb.error'> There is no member or method named m_vecpfx.: > path=0x3a09430) > at /home/aldyh/src/gcc/gcc/tree-ssa-threadupdate.c:2838 > (gdb) p ::debug(path) > [1] Registering jump thread: (8, 4) incoming edge; (4, 3) normal; > > It's threading 8->4->3, which looks perfectly reasonable: > > <bb 4> [local count: 1073741824]: > # i_5 = PHI <0(8), i_12(3)> > if (i_5 != 200) > goto <bb 3>; [99.00%] > else > goto <bb 5>; [1.00%] > > Note that i_5 is known to be 0 on the 8->4 edge. > > The loop info says that bb8 is the pre-header to loop 2 which starts at bb4. > So this technically crosses loops into bb4, but is allowed as there's an > exception when the first BB is in another block: > > // The first entry represents the block with an outgoing edge > // that we will redirect to the jump threading path. Thus we > // don't care about that block's loop father. So the threading at hand rotates the loop (which is only so-so OK), that might be problematic in case it creates a non-do-while loop after loop header copying. In this process it might also lose track of the loop, causing it to be re-discovered as separate entity which has problems of its own. IMHO we should avoid threadings through a loop header if the path ends in the loop itself, even if it doesn't introduce a new entry but just re-directs the existing one.
