From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 015FB385801A; Fri, 26 Mar 2021 23:53:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 015FB385801A From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/60488] missing uninitialized warning (address taken, VOP) Date: Fri, 26 Mar 2021 23:53:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor 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: cf_reconfirmed_on cf_known_to_fail 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: Fri, 26 Mar 2021 23:53:13 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60488 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2016-08-23 00:00:00 |2021-3-26 Known to fail|7.0 |11.0 --- Comment #6 from Martin Sebor --- Reconfirming with GCC 11. The problem is that when the address of a variable escapes, because GCC doe= sn't track when, when the function from which it escapes calls another that might access the escaped variable, the warning (as a result of relying on the conservative assumptions the optimizers must make) assumes the called funct= ion initializes the variable. Another example of this is function h() below. The irony (and I'd say the bug) here is that the warning uses the same conservative assumptions to trigger in cases when an equivalent same situat= ion might lead to the variable not having been initialized such as in g() below= .=20 These conflicting assumptions make the warning seem unpredictable. $ cat z.c && gcc -O2 -S -Wall z.c void f (void); int i, *p; int g (int j) { int x; if (i) // assume i is zero x =3D j + 1; f (); // assume call sets i if (i) return x; // issue -Wmaybe-uninitalized return i; } int h (int j) { int x; p =3D &x; // address of x escapes f (); // assume call sets x return x; // avoid warning here } z.c: In function =E2=80=98g=E2=80=99: z.c:14:12: warning: =E2=80=98x=E2=80=99 may be used uninitialized in this f= unction [-Wmaybe-uninitialized] 14 | return x; // issue -Wmaybe-uninitalized | ^ z.c:7:7: note: =E2=80=98x=E2=80=99 was declared here 7 | int x; | ^=