From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6557 invoked by alias); 29 Sep 2014 13:06:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 6528 invoked by uid 48); 29 Sep 2014 13:06:12 -0000 From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/19808] miss a warning about uninitialized members in constructor Date: Mon, 29 Sep 2014 13:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 3.4.4 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 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-SW-Source: 2014-09/txt/msg02680.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D19808 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org --- Comment #22 from Jason Merrill --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #21) > I just got hit by this bug. This can obviously be warned in the FE as cla= ng > does: >=20 > test.cc:4:11: warning: field 'j' is uninitialized when used here > [-Wuninitialized] > S() : i(j), j(1) {}=20 > ^ >=20 > simply by marking the members somehow as initialized or not, and when usi= ng > them realizing that they are still uninitialized. >=20 > Marek, Paolo, Jason? Any idea how to do this? It could be done specifically for uses in mem-initializers by walking the initializer in perform_mem_init to look for any references to members that haven't been marked yet. A more general warning that would cover, say, X x; x.x =3D x.y; would need support in the existing back end -Wuninitialized code. >>From gcc-bugs-return-462847-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 29 13:10:42 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10432 invoked by alias); 29 Sep 2014 13:10:41 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 10388 invoked by uid 48); 29 Sep 2014 13:10:37 -0000 From: "jason at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/62164] 5.0: ICE: error: Both section and comdat group is set Date: Mon, 29 Sep 2014 13:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jason at gcc dot gnu.org X-Bugzilla-Status: NEW 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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg02681.txt.bz2 Content-length: 807 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62164 Jason Merrill changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org --- Comment #3 from Jason Merrill --- (In reply to Jan Hubicka from comment #2) > The sections for COMDAT functions are used to drive code unification. I > wonder, do we want to support something like this (and expect that user > knows what he is doing and he won't, for example, drop multiple COMDATs into > one section) or just reject the attribute? What's wrong with dropping multiple COMDATs into one section? Don't we normally stick lots of COMDATs into .text?