On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64 bootstrap and break on
the warning, you can see that the uninitalized use is for
const_upper_3934 here:
<bb 102> [local count: 315357954]:
# const_upper_3934 = PHI <const_upper_3937(D)(101), _6707(293)>
if (_881 != 0)
goto <bb 103>; [50.00%]
else
goto <bb 106>; [50.00%]
<bb 103> [local count: 157678977]:
if (const_upper_3934 > _6699)
goto <bb 105>; [89.00%]
else
goto <bb 294>; [11.00%]
<bb 294> [local count: 17344687]:
<bb 104> [local count: 157678977]:
goto <bb 107>; [100.00%]
<bb 105> [local count: 140334290]:
stack_usage_map.481_3930 = stack_usage_map;
_6441 = const_upper_3934 - _6699;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PROBLEMATIC READ HERE
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_4819 = stack_usage_map.481_3930 + _6699;
__builtin_memset (_4819, 1, _6441);
goto <bb 104>; [11.00%]
const_upper_3934 could be undefined if it comes from BB101
(const_upper_3937(D)), but it only gets read for _881 != 0, so it
shouldn't warn.
I suggest -Wmaybe-uninitialized be turned off for that file until the
warning is fixed.
And yes, the proposed patch will also cure this, but the underlying
problem in the warning is still there.
You haven't shown enough context for me to agree or disagree. Are there
other preds to bb105? I hate these slimmed down dumps. I work better
with the full pred/succ lists. -fdump-tree-<whatever>-blocks-details :-)
It appears to me that for _881 != 0 we certainly flow into the read of
_const_upper_3934 in bb103 and bb105. Why do you think that's safe?
Jeff
