From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 31B9E3857366; Mon, 9 May 2022 13:05:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31B9E3857366 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings Date: Mon, 09 May 2022 13:05:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version cf_reconfirmed_on everconfirmed keywords bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2022 13:05:58 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105534 Richard Biener 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 --- Confirmed. I think we are not considering that # count_1 =3D PHI is actually the same variable plus that count_4 can be considered an uninitialized use even though it is (conditional) count_4 =3D 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-uninitialize= d] 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-uninitializ= ed] 4 | return count2; | ^~~~~~ t2.c:2:16: note: 'count2' was declared here 2 | int count, count2; | ^~~~~~ and the IL is very similar: [local count: 365072224]: count_5 =3D count_4(D) + 1; # _1 =3D PHI 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.=