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/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.
Date: Fri, 02 Apr 2021 16:49:00 +0000	[thread overview]
Message-ID: <bug-78391-4-bVO0cLgAB3@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-78391-4@http.gcc.gnu.org/bugzilla/>

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=19808
             Status|NEW                         |ASSIGNED
          Component|c++                         |middle-end

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
In bug 19808 comment #38 Jason explains why the CLOBBER isn't present in the
constructor, so that's not a bug.  In light of that, I'm not sure the request
can be implemented without introducing what are strictly speaking false
positives like those Clang suffers from.  In the test case below, the global a
is implicitly zeroed out first and then its members are explicitly assigned, so
there is no uninitialized read.

At the same time, I suspect the result of this initialization is probably not
going to be what the author intended, and so warning on it regardless might
actually be useful (admittedly, issuing -Wuninitialized in this case would be a
bit misleading).  So with that, -Wuninitialized or -Wmaybe-uninitialized in the
middle end could be probably enhanced to detect this pattern of intialization
dependencies.  Marek submitted a C++ patch for a subset of pr19808 last
November but I'm not sure it handled this case.  The patch was also not
approved as Jason's preference was to detect these things in the middle end. 
So let me reassign this back to the middle end and try to remember to get to it
for GCC 12.

$ cat t.C && clang -S t.C
struct A { int x = w; int w = 10; };

A a;
t.C:1:20: warning: field 'w' is uninitialized when used here [-Wuninitialized]
struct A { int x = w; int w = 10; };
                   ^
t.C:3:3: note: in implicit default constructor for 'A' first required here
A a;
  ^
t.C:1:8: note: during field initialization in the implicit default constructor
struct A { int x = w; int w = 10; };
       ^
1 warning generated.

  parent reply	other threads:[~2021-04-02 16:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-78391-4@http.gcc.gnu.org/bugzilla/>
2021-04-01  0:38 ` msebor at gcc dot gnu.org
2021-04-01  0:46 ` [Bug c++/78391] " msebor at gcc dot gnu.org
2021-04-02 16:49 ` msebor at gcc dot gnu.org [this message]
2021-04-02 16:51 ` [Bug middle-end/78391] " msebor at gcc dot gnu.org
2021-11-19 16:20 ` egallager at gcc dot gnu.org
2022-01-26 17:32 ` msebor at gcc dot gnu.org
2022-05-06  8:29 ` jakub at gcc dot gnu.org
2023-05-08 12:21 ` 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-78391-4-bVO0cLgAB3@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: link
Be 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).