Bug 97353 - -Wuninitialized should warn about reading condition in do-loop
Summary: -Wuninitialized should warn about reading condition in do-loop
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 11.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
Reported: 2020-10-09 14:23 UTC by Marek Polacek
Modified: 2021-04-12 19:46 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2021-04-12 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Marek Polacek 2020-10-09 14:23:22 UTC
Here in the first iteration of the loop we continue, which jumps to the end of the loop where we read ok which hasn't yet been initialized, but we issue no warning:

int main()
  int ok;
  int n = 0;
      if (n == 1)
      ok = n >= 2;
  while (ok == 0);

clang-tidy detects this.  This was distilled from libmpc.
Comment 1 Richard Biener 2020-10-12 06:16:37 UTC
We're likely threading this away before the late diagnostic.
Comment 2 Martin Sebor 2021-04-12 19:46:59 UTC
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]
    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]
    goto <bb 7>; [INV]

  <bb 7> :
  _9 = 0;

  <bb 8> :
  # VUSE <.MEM_10(D)>
  return _9;