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.
Similarly in the back threader profitability code:
/* Remember, blocks in the path are stored in opposite order
in the PATH array. The last entry in the array 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, nor how many statements are in that block because
it will not be copied or whether or not it ends in a multiway
branch. */
For reference, here is the full IL:
int i;
int _1;
int _2;
int _3;
int b_j.3_4;
<bb 2> [local count: 1327096]:
b_j = 1;
goto <bb 6>; [100.00%]
<bb 3> [local count: 1063004409]:
_1 = b_j.3_4 + -1;
_2 = a[i_5][_1];
a[i_5][b_j.3_4] = _2;
i_12 = i_5 + 1;
<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%]
<bb 5> [local count: 10737416]:
_3 = b_j.3_4 + 1;
b_j = _3;
<bb 6> [local count: 12064512]:
b_j.3_4 = b_j;
if (b_j.3_4 <= 199)
goto <bb 8>; [89.00%]
else
goto <bb 7>; [11.00%]
<bb 8> [local count: 10737416]:
goto <bb 4>; [100.00%]
<bb 7> [local count: 1327096]:
return;
I think this is a problem elsewhere.
