https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97353
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
Severity|normal |enhancement
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=18501
Last reconfirmed| |2021-04-12
Blocks| |24639
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
With -O2 the function is optimized to a return statement before the late
warning runs so there's nothing to do there.
With -O1 the uninitialized variable is optimized out in CCP3 so there's nothing
to warn about either.
With -O0 the uninitialized read is unconditional in bb 3 in the IL below but
the warning doesn't analyze PHIs at that level so the bug isn't detected.
Running the PHI analysis early (at -O0) would solve a whole class of false
negatives. If done indiscriminately, it would also introduce a ton of false
positives unless perhaps the warning ran CCP first (without actually changing
the CFG). A discussion of these problems is in pr18501. Without the help of
CCP the early warning could also trigger for unconditionally reachable PHI
reads like the one in the test case. So with that, let me confirm this
request. (The test case is too contrived to be worth worrying about on its own
since the loop doesn't do anything and can be optimized away regardless of
whether ok is initialized. But it may be representative of similar but less
contrived cases where the early warning could expose a real bug).
int main ()
{
int n;
int ok;
int D.1952;
_Bool _1;
int _9;
<bb 2> :
n_5 = 0;
<bb 3> :
# ok_2 = PHI <ok_6(D)(2), ok_3(6)>
# n_4 = PHI <n_5(2), n_7(6)>
n_7 = n_4 + 1;
if (n_7 == 1)
goto <bb 4>; [INV]
else
goto <bb 5>; [INV]
<bb 4> :
// predicted unlikely by continue predictor.
goto <bb 6>; [INV]
<bb 5> :
_1 = n_7 > 1;
ok_8 = (int) _1;
<bb 6> :
# ok_3 = PHI <ok_2(4), ok_8(5)>
if (ok_3 == 0)
goto <bb 3>; [INV]
else
goto <bb 7>; [INV]
<bb 7> :
_9 = 0;
<bb 8> :
<L5>:
# VUSE <.MEM_10(D)>
return _9;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
