* [Bug c++/19808] miss a warning about uninitialized members in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
@ 2013-07-17 9:26 ` redi at gcc dot gnu.org
2014-09-27 20:29 ` manu at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: redi at gcc dot gnu.org @ 2013-07-17 9:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nishant.031 at gmail dot com
--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 57917 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized members in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
2013-07-17 9:26 ` [Bug c++/19808] miss a warning about uninitialized members in constructor redi at gcc dot gnu.org
@ 2014-09-27 20:29 ` manu at gcc dot gnu.org
2014-09-29 13:06 ` jason at gcc dot gnu.org
` (14 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: manu at gcc dot gnu.org @ 2014-09-27 20:29 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 10969 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2005-05-09 00:52:15 |2014-9-27
CC| |mpolacek at gcc dot gnu.org,
| |paolo.carlini at oracle dot com
--- Comment #21 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I just got hit by this bug. This can obviously be warned in the FE as clang
does:
test.cc:4:11: warning: field 'j' is uninitialized when used here
[-Wuninitialized]
S() : i(j), j(1) {}
^
simply by marking the members somehow as initialized or not, and when using
them realizing that they are still uninitialized.
Marek, Paolo, Jason? Any idea how to do this?
>From gcc-bugs-return-462728-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 20:40:12 2014
Return-Path: <gcc-bugs-return-462728-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14120 invoked by alias); 27 Sep 2014 20:40:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14063 invoked by uid 48); 27 Sep 2014 20:40:08 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
Date: Sat, 27 Sep 2014 20:40: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.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu 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:
Message-ID: <bug-2972-4-ebd1veILD9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-2972-4@http.gcc.gnu.org/bugzilla/>
References: <bug-2972-4@http.gcc.gnu.org/bugzilla/>
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/msg02562.txt.bz2
Content-length: 1135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972
--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #14)
> Created attachment 20817 [details]
> better -Wmeminit patch
>
> This version ignores empty classes and checks for a nontrivial default ctor
> instead of layout_pod_type.
>
> This patch doesn't enable the warning unless explicity requested. I realise
> that this warning is about enforcing style ("members should be initialised
> in the mem-initializer-list not in the ctor body") but that's ok because
> it's my preferred style, I just don't want the compiler to enforce other
> people's preferred style ;)
Perhaps a better alternative is to warn only if the uninitialized member is
used in a mem-initializer. Then, when building the constructor call, mark the
uninitialized members somehow as uninitialized for the middle-end, and let the
middle-end handle the cases in the body of the constructor. The first part
would already fix PR19808. The second part will fix this bug with fewer false
positives than the proposed patch.
>From gcc-bugs-return-462729-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 20:52:48 2014
Return-Path: <gcc-bugs-return-462729-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17873 invoked by alias); 27 Sep 2014 20:52:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17851 invoked by uid 48); 27 Sep 2014 20:52:44 -0000
From: "Bruce at Daihls dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63394] New: Segmentation Fault with -O3 flag on ARM v61 Processor
Date: Sat, 27 Sep 2014 20:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Bruce at Daihls dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-63394-4@http.gcc.gnu.org/bugzilla/>
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/msg02563.txt.bz2
Content-length: 1126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63394
Bug ID: 63394
Summary: Segmentation Fault with -O3 flag on ARM v61 Processor
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Bruce at Daihls dot com
Created attachment 33589
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33589&action=edit
Preprocessed file layer3.c, from lame
gcc: 4.8.2 20131212 (Red Hat 4.8.2-8)
system: Raspberry Pi, ARMv6-compatible processor rev 7 (v6l)
gcc build options: unknown
cmd line: gcc -I. -I.. -I../include -I. -I../libmp3lame -I.. -O3 -c layer3.c
output:
layer3.c: In function ΓÇÿhip_init_tables_layer3ΓÇÖ:
layer3.c:1871:1: internal compiler error: Segmentation fault
}
^
This occurs when building lame-3.99.3.tar.gz. The shortened command line that
will cause the segmentation fault is above, with the output from the compiler.
When the -O3 flag is removed, it compiles without error.
>From gcc-bugs-return-462730-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 20:56:26 2014
Return-Path: <gcc-bugs-return-462730-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19916 invoked by alias); 27 Sep 2014 20:56:26 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19897 invoked by uid 48); 27 Sep 2014 20:56:22 -0000
From: "bernardwidynski at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/63395] New: Cygwin vs Cygwin64 Floating Point Discrepancy
Date: Sat, 27 Sep 2014 20:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernardwidynski at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-63395-4@http.gcc.gnu.org/bugzilla/>
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/msg02564.txt.bz2
Content-length: 2383
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc395
Bug ID: 63395
Summary: Cygwin vs Cygwin64 Floating Point Discrepancy
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: bernardwidynski at gmail dot com
Created attachment 33590
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id3590&actioníit
C source program that prints the floating point output
I transitioned from Cygwin to Cygwin64 and noticed that one of my programs
produces differing floating point output.
I realize that floating point round off can produce differing outputs on
different computer platforms, but Cygwin and Cygwin64 are each running on the
same computer and the same floating point hardware is used. I noticed that
with identical input values, the output values are different. I printed the
floating point number in hexadecimal format and the outputs do not match. See
the attached flterr.c program. This program computes the square of a
floating-point number. The value of x before and after the square is printed.
There are two iterations. On the first iteration Cygwin and Cygwin64 produce
the same output: 0x3ff441395eb3a15d. But on the second iteration, differing
outputs are printed: For Cygwin, the output is 0x400b56a2041cc08e. For
Cygwin64, the output is 0x400b56a2041cc08d. See the attached files flterr.out
and flterr64.out. Is there some explanation for this? This seems to be an
error.
I am running Cygwin and Cygwin64 on the same computer. The information from
the system display shows the following:
HP Pavilion dv5 Notebook PC
Windows 7 Home Premium
ServicePack 1
AMD Turion(tm) II P540 Dual-Core Processor 2.40 GHz
4.00 GB (3.74 GB usable)
64-bit Operating System
The files gcc-v.out and gcc-v64.out show the gcc output when executing the make
command. I've also attached cygcheck.out and cygcheck64.out for each
installation.
I thought perhaps that this may be a hardware error and I tried this same
program on another computer which has the the following processor:
AMD Phenom(tm) II N620 Dual-Core Processor 2.80 GHz
The same error occurred.
Apparently Cygwin and Cygwin64 are handling floating point differently and do
not produce identical outputs.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized members in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
2013-07-17 9:26 ` [Bug c++/19808] miss a warning about uninitialized members in constructor redi at gcc dot gnu.org
2014-09-27 20:29 ` manu at gcc dot gnu.org
@ 2014-09-29 13:06 ` jason at gcc dot gnu.org
2014-09-29 14:35 ` manu at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: jason at gcc dot gnu.org @ 2014-09-29 13:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #22 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #21)
> I just got hit by this bug. This can obviously be warned in the FE as clang
> does:
>
> test.cc:4:11: warning: field 'j' is uninitialized when used here
> [-Wuninitialized]
> S() : i(j), j(1) {}
> ^
>
> simply by marking the members somehow as initialized or not, and when using
> them realizing that they are still uninitialized.
>
> 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 = 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: <gcc-bugs-return-462847-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-62164-4-NcAuFghIsH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62164-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62164-4@http.gcc.gnu.org/bugzilla/>
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?idb164
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
(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?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized members in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-09-29 13:06 ` jason at gcc dot gnu.org
@ 2014-09-29 14:35 ` manu at gcc dot gnu.org
2014-11-15 23:11 ` [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list " anthony.brandon at gmail dot com
` (12 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: manu at gcc dot gnu.org @ 2014-09-29 14:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #23 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #22)
> 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.
Great! If I find some time in the following weeks, I will give it a try.
> A more general warning that would cover, say,
>
> X x;
> x.x = x.y;
>
> would need support in the existing back end -Wuninitialized code.
That is PR2972 and I think fixing this one is a prerequisite for fixing that
one. So let's go step by step.
>From gcc-bugs-return-462855-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Sep 29 14:43:46 2014
Return-Path: <gcc-bugs-return-462855-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7138 invoked by alias); 29 Sep 2014 14:43:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7021 invoked by uid 48); 29 Sep 2014 14:43:41 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62056] Long compile times with large tuples
Date: Mon, 29 Sep 2014 14:43: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: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-62056-4-SWKXbDRPQF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62056-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62056-4@http.gcc.gnu.org/bugzilla/>
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/msg02689.txt.bz2
Content-length: 838
https://gcc.gnu.org/bugzilla/show_bug.cgi?idb056
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
tr1::tuple doesn't support perfect-forwarding or move semantics
tr1::tuple doesn't support uses-allocator construction
tr1::tuple doesn't support 'final' classes
tr1::tuple doesn't have correct exception specifications
tr1::tuple doesn't prevent implicit conversions that would use explicit
constructors
tr1::tuple doesn't support tuple concatenation
If you can add all those features to the <tr1/tuple> implementation so that it
meets the C++11 requirements and it still compiles faster then I'd be
interested in your analysis of the remaining differences. Otherwise I'm going
to assume the difference is because the <tuple> header contains more than twice
as many lines of code and several additional features.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-09-29 14:35 ` manu at gcc dot gnu.org
@ 2014-11-15 23:11 ` anthony.brandon at gmail dot com
2014-11-16 19:14 ` anthony.brandon at gmail dot com
` (11 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: anthony.brandon at gmail dot com @ 2014-11-15 23:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Anthony Brandon <anthony.brandon at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anthony.brandon at gmail dot com
--- Comment #24 from Anthony Brandon <anthony.brandon at gmail dot com> ---
Hi,
> 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.
I've been working on this using this approach.
At the moment I can detect and give a warning for something like:
struct S
{
int i, j;
S() : i(j), j(1) {}
};
However it doesn't cover cases like i(j+1), and in the case of i(i) there would
currently be two warnings (due to -Winit-self).
Lastly, the warning is given like so:
a.cpp:8:2: warning: ‘S::i’ is initialized with uninitialized field ‘S::j’
[-Wuninitialized]
S() : i(j), j(b) {}
^
So I have a couple of questions:
* How to get the right location for the mark. In other words:
S() : i(j), j(b) {}
^
* Is there a function to traverse a tree structure looking for a particular
tree (or some other way to get things like i(j+1) to work)?
* Should this give a warning in the case of i(i)?
>From gcc-bugs-return-466925-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 15 23:21:51 2014
Return-Path: <gcc-bugs-return-466925-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13609 invoked by alias); 15 Nov 2014 23:21:51 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13278 invoked by uid 48); 15 Nov 2014 23:21:47 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63898] [5 Regression] r217560 caused segfault building 462.libquantum from cpu2006
Date: Sat, 15 Nov 2014 23:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-63898-4-dWxcoUCOQg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63898-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63898-4@http.gcc.gnu.org/bugzilla/>
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-11/txt/msg01397.txt.bz2
Content-length: 143
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc898
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Where is the testcase?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-11-15 23:11 ` [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list " anthony.brandon at gmail dot com
@ 2014-11-16 19:14 ` anthony.brandon at gmail dot com
2020-10-21 23:28 ` mpolacek at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: anthony.brandon at gmail dot com @ 2014-11-16 19:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #25 from Anthony Brandon <anthony.brandon at gmail dot com> ---
Never mind the second question, I found walk_tree.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2014-11-16 19:14 ` anthony.brandon at gmail dot com
@ 2020-10-21 23:28 ` mpolacek at gcc dot gnu.org
2020-11-12 15:07 ` mpolacek at gcc dot gnu.org
` (9 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2020-10-21 23:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |smuccione at agisent dot com
--- Comment #47 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
*** Bug 97525 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-10-21 23:28 ` mpolacek at gcc dot gnu.org
@ 2020-11-12 15:07 ` mpolacek at gcc dot gnu.org
2020-11-13 3:07 ` mpolacek at gcc dot gnu.org
` (8 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2020-11-12 15:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mpolacek at gcc dot gnu.org
--- Comment #48 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I have a patch that for this:
// PR c++/19808
// { dg-do compile { target c++11 } }
// { dg-options "-Wuninitialized" }
struct S {
int i, j, k, l;
S() : i(j), // { dg-warning "field .S::j. is uninitialized when used here" }
j(1),
k(l + 1), // { dg-warning "field .S::l. is uninitialized when used
here" }
l(2) { }
};
struct A {
int a, b, c;
A() : a(b // { dg-warning "field .A::b. is uninitialized when used here" }
+ c) { } // { dg-warning "field .A::c. is uninitialized when used
here" }
};
struct B {
int &r;
int *p;
int a;
B() : r(a), p(&a), a(1) { }
};
struct C {
const int &r1, &r2;
C () : r1(r2), // { dg-warning "reference .C::r2. is not yet bound to a value
when used here" }
r2(r1) { }
};
struct D {
int a = 1;
int b = 2;
D() : a(b + 1), b(a + 1) { } // { dg-warning "field .D::b. is uninitialized
when used here" }
};
struct E {
int a = 1;
E() : a(a + 1) { } // { dg-warning "field .E::a. is uninitialized when used
here" }
};
struct F {
int a = 1;
int b;
F() : b(a + 1) { }
};
struct bar {
bar() {}
bar(bar&) {}
};
class foo {
bar first;
bar second;
public:
foo() : first(second) {} // { dg-warning "field .foo::second. is
uninitialized when used here" }
};
does this:
$ ./cc1plus -quiet -Wuninitialized Wuninitialized-12.C
Wuninitialized-12.C: In constructor ‘S::S()’:
Wuninitialized-12.C:7:11: warning: field ‘S::j’ is uninitialized when used here
[-Wuninitialized]
7 | S() : i(j), // { dg-warning "field .S::j. is uninitialized when used
here" }
| ^
Wuninitialized-12.C:9:11: warning: field ‘S::l’ is uninitialized when used here
[-Wuninitialized]
9 | k(l + 1), // { dg-warning "field .S::l. is uninitialized when
used here" }
| ^
Wuninitialized-12.C: In constructor ‘A::A()’:
Wuninitialized-12.C:15:11: warning: field ‘A::b’ is uninitialized when used
here [-Wuninitialized]
15 | A() : a(b // { dg-warning "field .A::b. is uninitialized when used
here" }
| ^
Wuninitialized-12.C:16:13: warning: field ‘A::c’ is uninitialized when used
here [-Wuninitialized]
16 | + c) { } // { dg-warning "field .A::c. is uninitialized when
used here" }
| ^
Wuninitialized-12.C: In constructor ‘C::C()’:
Wuninitialized-12.C:28:13: warning: reference ‘C::r2’ is not yet bound to a
value when used here [-Wuninitialized]
28 | C () : r1(r2), // { dg-warning "reference .C::r2. is not yet bound to
a value when used here" }
| ^~
Wuninitialized-12.C: In constructor ‘D::D()’:
Wuninitialized-12.C:35:11: warning: field ‘D::b’ is uninitialized when used
here [-Wuninitialized]
35 | D() : a(b + 1), b(a + 1) { } // { dg-warning "field .D::b. is
uninitialized when used here" }
| ^
Wuninitialized-12.C: In constructor ‘E::E()’:
Wuninitialized-12.C:40:11: warning: field ‘E::a’ is uninitialized when used
here [-Wuninitialized]
40 | E() : a(a + 1) { } // { dg-warning "field .E::a. is uninitialized
when used here" }
| ^
Wuninitialized-12.C: In constructor ‘foo::foo()’:
Wuninitialized-12.C:58:17: warning: field ‘foo::second’ is uninitialized when
used here [-Wuninitialized]
58 | foo() : first(second) {} // { dg-warning "field .foo::second. is
uninitialized when used here" }
| ^~~~~~
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-11-12 15:07 ` mpolacek at gcc dot gnu.org
@ 2020-11-13 3:07 ` mpolacek at gcc dot gnu.org
2021-11-05 23:33 ` mpolacek at gcc dot gnu.org
` (7 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2020-11-13 3:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-11-13 3:07 ` mpolacek at gcc dot gnu.org
@ 2021-11-05 23:33 ` mpolacek at gcc dot gnu.org
2021-11-19 3:38 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2021-11-05 23:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #49 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Patch resurrected for GCC 12:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583544.html
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2021-11-05 23:33 ` mpolacek at gcc dot gnu.org
@ 2021-11-19 3:38 ` cvs-commit at gcc dot gnu.org
2021-11-19 3:54 ` mpolacek at gcc dot gnu.org
` (5 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-19 3:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #50 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:
https://gcc.gnu.org/g:0790c8aacdfb4fd096aa580dae0fe49172c43ab2
commit r12-5391-g0790c8aacdfb4fd096aa580dae0fe49172c43ab2
Author: Marek Polacek <polacek@redhat.com>
Date: Tue Nov 10 20:07:24 2020 -0500
c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]
2021 update: Last year I posted a version of this patch:
<https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html>
but it didn't make it in. The main objection seemed to be that the
patch tried to do too much, and overlapped with the ME uninitialized
warnings. Since the patch used walk_tree without any data flow info,
it issued false positives for things like a(0 ? b : 42) and similar.
I'll admit I've been dreading resurrecting this because of the lack
of clarity about where we should warn about what. On the other hand,
I think we really should do something about this. So I've simplified
the original patch as much as it seemed reasonable. For instance, it
doesn't even attempt to handle cases like "a((b = 42)), c(b)" -- for
these I simply give up for the whole mem-initializer (but who writes
code like that, anyway?). I also give up when a member is initialized
with a function call, because we don't know what the call could do.
See Wuninitialized-17.C, for which clang emits a false positive but
we don't. I remember having a hard time dealing with initializer lists
in my previous patch, so now I only handle simple a{b} cases, but no
more. It turned out that this abridged version still warns about 90%
cases where users would expect a warning.
More complicated cases are left for the ME, which, for unused inline
functions, will only warn with -fkeep-inline-functions, but so be it.
(This is bug 21678.)
This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like
struct A {
int a;
int b;
A() : b(1), a(b) { }
};
where the field 'b' is used uninitialized because the order of member
initializers in the member initializer list is irrelevant; what matters
is the order of declarations in the class definition.
I've implemented this by keeping a hash set holding fields that are not
initialized yet, so at first it will be {a, b}, and after initializing
'a' it will be {b} and so on. Then I use walk_tree to walk the
initializer and if we see that an uninitialized object is used, we warn.
Of course, when we use the address of the object, we may not warn:
struct B {
int &r;
int *p;
int a;
B() : r(a), p(&a), a(1) { } // ok
};
Likewise, don't warn in unevaluated contexts such as sizeof. Classes
without an explicit initializer may still be initialized by their
default constructors; whether or not something is considered initialized
is handled in perform_member_init, see member_initialized_p.
PR c++/19808
PR c++/96121
gcc/cp/ChangeLog:
* init.c (perform_member_init): Remove a forward declaration.
Walk the initializer using find_uninit_fields_r. New parameter
to track uninitialized fields. If a member is initialized,
remove it from the hash set.
(perform_target_ctor): Return the initializer.
(struct find_uninit_data): New class.
(find_uninit_fields_r): New function.
(find_uninit_fields): New function.
(emit_mem_initializers): Keep and initialize a set holding fields
that are not initialized. When handling delegating constructors,
walk the constructor tree using find_uninit_fields_r. Also when
initializing base clases. Pass uninitialized down to
perform_member_init.
gcc/ChangeLog:
* doc/invoke.texi: Update documentation for -Wuninitialized.
* tree.c (stabilize_reference): Set location.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wuninitialized-14.C: New test.
* g++.dg/warn/Wuninitialized-15.C: New test.
* g++.dg/warn/Wuninitialized-16.C: New test.
* g++.dg/warn/Wuninitialized-17.C: New test.
* g++.dg/warn/Wuninitialized-18.C: New test.
* g++.dg/warn/Wuninitialized-19.C: New test.
* g++.dg/warn/Wuninitialized-20.C: New test.
* g++.dg/warn/Wuninitialized-21.C: New test.
* g++.dg/warn/Wuninitialized-22.C: New test.
* g++.dg/warn/Wuninitialized-23.C: New test.
* g++.dg/warn/Wuninitialized-24.C: New test.
* g++.dg/warn/Wuninitialized-25.C: New test.
* g++.dg/warn/Wuninitialized-26.C: New test.
* g++.dg/warn/Wuninitialized-27.C: New test.
* g++.dg/warn/Wuninitialized-28.C: New test.
* g++.dg/warn/Wuninitialized-29.C: New test.
* g++.dg/warn/Wuninitialized-30.C: New test.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2021-11-19 3:38 ` cvs-commit at gcc dot gnu.org
@ 2021-11-19 3:54 ` mpolacek at gcc dot gnu.org
2021-11-19 9:09 ` dcb314 at hotmail dot com
` (4 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2021-11-19 3:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #51 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
At last, implemented.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2021-11-19 3:54 ` mpolacek at gcc dot gnu.org
@ 2021-11-19 9:09 ` dcb314 at hotmail dot com
2021-11-19 11:00 ` dcb314 at hotmail dot com
` (3 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: dcb314 at hotmail dot com @ 2021-11-19 9:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #52 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Marek Polacek from comment #51)
> At last, implemented.
Marvellous.
I will test it by compiling Fedora rawhide and report back
with any errors.
Nearly 17 years is quite a wait for a fix.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2021-11-19 9:09 ` dcb314 at hotmail dot com
@ 2021-11-19 11:00 ` dcb314 at hotmail dot com
2021-11-19 11:09 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
16 siblings, 0 replies; 17+ messages in thread
From: dcb314 at hotmail dot com @ 2021-11-19 11:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #53 from David Binderman <dcb314 at hotmail dot com> ---
I am not sure if this belongs here or in a separate bug report,
but given this code:
class AllocatorWithCleanup {
public:
int *allocate(int, void *);
};
class SecBlock {
SecBlock() : m_ptr(m_alloc.allocate(0, nullptr)) {}
AllocatorWithCleanup m_alloc;
int *m_ptr;
};
Recent clang-14 thinks it is ok and new gcc trunk thinks it isn't.
$ /home/dcb/llvm/results/bin/clang++ -c -O2 -Wall bug774.cc
$ /home/dcb/llvm/results/bin/clang++ -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
f95bd18b5faa6a5af4b5786312c373c5b2dce687)
$ /home/dcb/gcc/results/bin/gcc -c -O2 -Wall bug774.cc
bug774.cc: In constructor ‘SecBlock::SecBlock()’:
bug774.cc:6:22: warning: member ‘SecBlock::m_alloc’ is used uninitialized
[-Wuninitialized]
6 | SecBlock() : m_ptr(m_alloc.allocate(0, nullptr)) {}
| ^~~~~~~
$ /home/dcb/gcc/results/bin/gcc -v
gcc version 12.0.0 20211119 (experimental) (0e510ab53414430e)
$
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2021-11-19 11:00 ` dcb314 at hotmail dot com
@ 2021-11-19 11:09 ` redi at gcc dot gnu.org
2021-11-19 16:57 ` mpolacek at gcc dot gnu.org
2021-11-23 20:02 ` cvs-commit at gcc dot gnu.org
16 siblings, 0 replies; 17+ messages in thread
From: redi at gcc dot gnu.org @ 2021-11-19 11:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #54 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Looks like it's missing a check for m_alloc having vacuous initialization, i.e.
not actually needing any initialization before it's usable.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2021-11-19 11:09 ` redi at gcc dot gnu.org
@ 2021-11-19 16:57 ` mpolacek at gcc dot gnu.org
2021-11-23 20:02 ` cvs-commit at gcc dot gnu.org
16 siblings, 0 replies; 17+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2021-11-19 16:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #55 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Aah, I should check is_empty_class before issuing the warning I guess.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
[not found] <bug-19808-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2021-11-19 16:57 ` mpolacek at gcc dot gnu.org
@ 2021-11-23 20:02 ` cvs-commit at gcc dot gnu.org
16 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-23 20:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
--- Comment #56 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:
https://gcc.gnu.org/g:4b1d3d8d732bea86c7b2aba46c2a437461020824
commit r12-5479-g4b1d3d8d732bea86c7b2aba46c2a437461020824
Author: Marek Polacek <polacek@redhat.com>
Date: Fri Nov 19 14:22:10 2021 -0500
c++: -Wuninitialized for mem-inits and empty classes [PR19808]
This fixes a bogus -Wuninitialized warning: there's nothing to initialize
in empty classes, so don't add them into our uninitialized set.
PR c++/19808
gcc/cp/ChangeLog:
* init.c (emit_mem_initializers): Don't add is_really_empty_class
members into uninitialized.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wuninitialized-28.C: Make a class nonempty.
* g++.dg/warn/Wuninitialized-29.C: Likewise.
* g++.dg/warn/Wuninitialized-31.C: New test.
^ permalink raw reply [flat|nested] 17+ messages in thread