[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |12.1.0
   Last reconfirmed|                            |2022-05-09
     Ever confirmed|0                           |1
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  I think we are not considering that

  # count_1 = PHI <count_3(D)(5), count_4(3)>

is actually the same variable plus that count_4 can be considered an
uninitialized use even though it is (conditional)

  count_4 = count_3(D) + 1;

instead what we are keying on is the uses of count_3(D) only, of which
one is in the PHI and one in the add.  Note that after emitting one
diagnostic we're silencing the other because we mark 'count' as being
already diagnosed.

If you modify the testcase to

int test(_Bool cond) {
    int count, count2;
    if (cond) return ++count;
    return count2;
}

you get

t2.c: In function 'test':
t2.c:3:22: warning: 'count' may be used uninitialized [-Wmaybe-uninitialized]
    3 |     if (cond) return ++count;
      |                      ^~~~~~~
t2.c:2:9: note: 'count' was declared here
    2 |     int count, count2;
      |         ^~~~~
t2.c:4:12: warning: 'count2' may be used uninitialized [-Wmaybe-uninitialized]
    4 |     return count2;
      |            ^~~~~~
t2.c:2:16: note: 'count2' was declared here
    2 |     int count, count2;
      |                ^~~~~~

and the IL is very similar:

  <bb 3> [local count: 365072224]:
  count_5 = count_4(D) + 1;

  # _1 = PHI <count_5(3), count2_3(D)(5)>

you would probably agree to the "may be used" kind used here in which case
it's exactly noticing that the same variable is used on all paths into the
PHI node.

If you'd say this is also a case of an unconditional uninitialized use
(it is!) then it might be even easier to implement this since we don't
need to prove the variables returned are the same ones, just that they
have uninitialized uses.