From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B315B383F84B; Tue, 27 Oct 2020 17:05:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B315B383F84B From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) Date: Tue, 27 Oct 2020 17:05:42 +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: 3.4.2 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement 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: cc 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: Tue, 27 Oct 2020 17:05:42 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D19430 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org --- Comment #35 from Martin Sebor --- GCC 11 issues a warning when the address of an uninitialized variable is pa= ssed to a function that takes a const pointer but it (still) doesn't warn when t= he address escapes. In both cases, it's possible for the called function to s= tore a value into the variable but because it's highly unlikely issuing a warning regardless would be appropriate. In addition, in cases where the address of the variable doesn't escape until after the function call its value cannot = be affected even when the address is assigned to a non-const pointer. The esc= ape analysis is flow insensitive so it alone cannot be relied on to make the distinction. But modifying variables this way is rare so issuing the warni= ng regardless is likely worthwhile. $ cat a.c && gcc -O2 -S -Wall a.c extern void f (const void*); int g (void) { int i; f (&i); // -Wmaybe-uninitialized return i; } int h (void) { extern const void *p; int i; f (0); p =3D &i; return i; // missing -Wmaybe-uninitialized } a.c: In function =E2=80=98int g()=E2=80=99: a.c:6:5: warning: =E2=80=98i=E2=80=99 may be used uninitialized [-Wmaybe-un= initialized] 6 | f (&i); | ~~^~~~ a.c:1:13: note: by argument 1 of type =E2=80=98const void*=E2=80=99 to =E2= =80=98void f(const void*)=E2=80=99 declared here 1 | extern void f (const void*); | ^ a.c:5:7: note: =E2=80=98i=E2=80=99 declared here 5 | int i; | ^=