[Bug c++/19808] miss a warning about uninitialized members in constructor

[Bug c++/19808] miss a warning about uninitialized members in constructor

[redi at gcc dot gnu.org]

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. ***

[Bug c++/19808] miss a warning about uninitialized members in constructor

[manu at gcc dot gnu.org]

[-- 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.

[Bug c++/19808] miss a warning about uninitialized members in constructor

[jason at gcc dot gnu.org]

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?

[Bug c++/19808] miss a warning about uninitialized members in constructor

[manu at gcc dot gnu.org]

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.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[anthony.brandon at gmail dot com]

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?

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[anthony.brandon at gmail dot com]

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.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org]

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. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org]

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" }
      |                 ^~~~~~

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org]

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

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org]

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

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[cvs-commit at gcc dot gnu.org]

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.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org]

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.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[dcb314 at hotmail dot com]

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.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[dcb314 at hotmail dot com]

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) 
$

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[redi at gcc dot gnu.org]

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.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[mpolacek at gcc dot gnu.org]

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.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[cvs-commit at gcc dot gnu.org]

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.