https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #13 from qinzhao at gcc dot gnu.org ---
>when adding -fno-tree-sink, the warning disappeared.
Before tree-sinking optimization, the IR is: (c.151t.pre)
<bb 2> [local count: 1073741824]:
c.0_1 = c;
_2 = c.0_1 + 1;
_5 = strlen (_2);
_8 = (int) _5;
f_6 = (long int) _8;
if (c.0_1 == 0B)
goto <bb 3>; [17.43%]
else
goto <bb 5>; [82.57%]
<bb 5> [local count: 886588624]:
goto <bb 4>; [100.00%]
<bb 3> [local count: 187153200]:
a (f_6);
<bb 4> [local count: 1073741824]:
return;
With the tree-sinking optimization, the IR becomes: (c.152t.sink1)
<bb 2> [local count: 1073741824]:
c.0_1 = c;
if (c.0_1 == 0B)
goto <bb 3>; [17.43%]
else
goto <bb 5>; [82.57%]
<bb 5> [local count: 886588624]:
goto <bb 4>; [100.00%]
<bb 3> [local count: 187153200]:
_2 = c.0_1 + 1;
_5 = strlen (_2);
_8 = (int) _5;
f_6 = (long int) _8;
a (f_6);
<bb 4> [local count: 1073741824]:
return;
>From the above, we can clearly see that, 4 statements including "_5 = strlen
(_2)" are sinked from basic block 2 down to basic block 3. The basic block 3 is
on the TRUE path of the condition "if (c.0_1 == 0B), therefore, compiler
definitely reports the error in the user code, i.e., "strlen (_2)" tries to
reference a NULL pointer.
This is a real bug in the user's source code.
Instead of a code duplication as jump threading optimization, tree-sinking
applies a code movement from a joint-point of a CFG to a specific path.
We might need to record such information.
