From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EAA253854829; Fri, 2 Apr 2021 16:49:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EAA253854829 From: "msebor at gcc dot 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 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: 7.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: msebor at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: target_milestone assigned_to see_also bug_status component 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, 02 Apr 2021 16:49:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D78391 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot g= nu.org See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=3D19808 Status|NEW |ASSIGNED Component|c++ |middle-end --- Comment #6 from Martin Sebor --- 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 reque= st can be implemented without introducing what are strictly speaking false positives like those Clang suffers from. In the test case below, the globa= l 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 n= ot 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 intializati= on 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= .=20 So let me reassign this back to the middle end and try to remember to get t= o it for GCC 12. $ cat t.C && clang -S t.C struct A { int x =3D w; int w =3D 10; }; A a; t.C:1:20: warning: field 'w' is uninitialized when used here [-Wuninitializ= ed] struct A { int x =3D w; int w =3D 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 construc= tor struct A { int x =3D w; int w =3D 10; }; ^ 1 warning generated.=