On 10/7/2021 2:15 AM, Aldy Hernandez wrote:
[Andrew, ranger comment embedded below.]
On 10/7/21 1:06 AM, Jeff Law wrote:
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?
My bad, there's some missing context.
The only way to get to BB101->BB102 is through:
<bb 100>
if (_6711 != 0)
goto <bb 101>; [5.50%]
else
goto <bb 293>; [94.50%]
And there's an implicit relation between _6711 and _811:
<bb 86>
...
if (_6711 != 0)
goto <bb 287>; [5.50%]
else
goto <bb 87>; [94.50%]
<bb 287> [local count: 17344687]:
goto <bb 88>; [100.00%]
<bb 87> [local count: 298013267]:
<bb 88> [local count: 315357954]:
# _881 = PHI <1(87), 0(287)>
That is, _6711 == !_881.
[Andrew, it'd be neat if we could teach ranger the relationship
between _6711 and _811 above. And also, that _881 is [0,1]. Perhaps
with the relation oracle, the uninit code could notice that a _6711
guard is also a !_811 guard.]
Ah, yes. This is one of the most common cases where we fail to detect
jump threads and/or fail to prune a path in the uninit warnings.
There's multiple instances of this BZ, though I don't have the #s handy
and the testcases are much smaller & easier to understand. I'm pretty
sure they're linked to the meta bug for threading or uninit warnings.
However, in this instance we may have a way out. When we record the
constant boolean equivalence for _881 talking the paths from 87 and 287
respectively, we could walk up the control dependency graph and derive
other values such as _6711 in this example. I'm pretty sure we don't
have the CDG built for DOM, but I do think we have it in the predicate
analysis engine, so we could at least prune the warning.
Jeff
