[Bug middle-end/97353] New: -Wuninitialized should warn about reading condition in do-loop

[Bug middle-end/97353] New: -Wuninitialized should warn about reading condition in do-loop

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97353

            Bug ID: 97353
           Summary: -Wuninitialized should warn about reading condition in
                    do-loop
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

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;
  do
    {
      n++;
      if (n == 1)
        continue;
      ok = n >= 2;
    }
  while (ok == 0);
}

clang-tidy detects this.  This was distilled from libmpc.

[Bug middle-end/97353] -Wuninitialized should warn about reading condition in do-loop

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97353

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We're likely threading this away before the late diagnostic.

[Bug middle-end/97353] -Wuninitialized should warn about reading condition in do-loop

[msebor at gcc dot gnu.org]

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