public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-19430-4-mx1NbkaXNB@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-19430-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org --- Comment #35 from Martin Sebor <msebor at gcc dot gnu.org> --- GCC 11 issues a warning when the address of an uninitialized variable is passed to a function that takes a const pointer but it (still) doesn't warn when the address escapes. In both cases, it's possible for the called function to store 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 escape 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 warning 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 = &i; return i; // missing -Wmaybe-uninitialized } a.c: In function ‘int g()’: a.c:6:5: warning: ‘i’ may be used uninitialized [-Wmaybe-uninitialized] 6 | f (&i); | ~~^~~~ a.c:1:13: note: by argument 1 of type ‘const void*’ to ‘void f(const void*)’ declared here 1 | extern void f (const void*); | ^ a.c:5:7: note: ‘i’ declared here 5 | int i; | ^
next prev parent reply other threads:[~2020-10-27 17:05 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-19430-4@http.gcc.gnu.org/bugzilla/> 2013-11-21 3:11 ` [Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning vincent-gcc at vinc17 dot net 2013-11-21 12:16 ` [Bug middle-end/19430] taking address of a var " rguenth at gcc dot gnu.org 2013-11-21 18:31 ` manu at gcc dot gnu.org 2013-11-21 23:57 ` vincent-gcc at vinc17 dot net 2020-10-27 17:05 ` msebor at gcc dot gnu.org [this message] 2021-04-01 0:23 ` [Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM) msebor at gcc dot gnu.org 2022-08-29 13:08 ` rguenth at gcc dot gnu.org 2022-08-29 13:16 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-19430-4-mx1NbkaXNB@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).