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

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

[adl at gnu dot org]

I just ran into bogus code similar to the following.  
(The code is bogus, not GCC, but I believe GCC could have helped.)

// main.cc
#include <iostream>

struct A
{
  A(int x) : x(x) {};
  int call_me() { return x; }
  int x;
};

struct B
{
  B(A* a) : i(the_a->call_me()), the_a(a) {}
  int i;
  A* the_a;
};

int
main()
{
  A a(20);
  B b(&a);
  std::cout << b.i << std::endl;
}

% g++ -O2 -Wall main.cc
% ./a.out
1328900

This displays 1328900 (or any other value) instead of 20 because
the_a->call_me() is invoked before the_a is initialized in 
B's constructor.

It would be useful if g++ could diagnose such use of uninitialized
members in constructors, just like it does for local variables.

-- 
           Summary: miss a warning about uninitialized members in
                    constructor
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: adl at gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-02-07 21:53 -------
Confirmed. We should get a warning for this code, but don't: 
---------------------- 
struct S 
{ 
    int i, j; 
    S() : i(j), j(1) {} 
}; 
 
S s; 
----------------------- 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2005-02-07 21:53:37
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-07 21:56 -------
This is related to PR 2972 and PR 18016.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

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

[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

[bart dot vanassche at gmail dot com]

------- Comment #19 from bart dot vanassche at gmail dot com  2010-02-25 07:05 -------
(In reply to comment #17)
> (In reply to comment #15)
> > Alternatively, the C++ front-end could create an uninitialized variable for
> > each member variable. Initialize those, then, at the very end of the
> > constructor, assigned each clone variable to the appropriate member.
> 
> That would break if the constructor calls any other member functions.

It is even possible to trigger member function calls from inside the
initializer list. This will result in member functions being invoked for a
partially initialized object. Some compilers emit a warning when the 'this'
pointer is passed as a function argument from inside the initializer list.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[bart dot vanassche at gmail dot com]

------- Comment #18 from bart dot vanassche at gmail dot com  2010-02-25 07:00 -------
(In reply to comment #16)
> (In reply to comment #14)
> > > (In reply to comment #8)
> > > > Incidentally, perhaps we should mark the this parameter as __restrict...
> > 
> > I don't see how this would be correct (or useful).
> 
> Hmm, I suppose it is possible to have another identical pointer in the case of
> placement new.

Invoking a constructor twice successively via placement new is questionable
programming style. One should use plain functions instead of abusing
constructors.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[jason at gcc dot gnu dot org]

------- Comment #17 from jason at gcc dot gnu dot org  2010-02-24 20:45 -------
(In reply to comment #15)
> Alternatively, the C++ front-end could create an uninitialized variable for
> each member variable. Initialize those, then, at the very end of the
> constructor, assigned each clone variable to the appropriate member.

That would break if the constructor calls any other member functions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[jason at gcc dot gnu dot org]

------- Comment #16 from jason at gcc dot gnu dot org  2010-02-24 20:44 -------
(In reply to comment #14)
> > (In reply to comment #8)
> > > Incidentally, perhaps we should mark the this parameter as __restrict...
> 
> I don't see how this would be correct (or useful).

Hmm, I suppose it is possible to have another identical pointer in the case of
placement new.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[manu at gcc dot gnu dot org]

------- Comment #15 from manu at gcc dot gnu dot org  2010-02-24 20:30 -------
(In reply to comment #12)
> Is there nothing pointed by this that could be initialized before calling the
> > constructor?
> 
> Nothing.

Then for sure someone can write a generic/gimple pass that detects this case
before lowering. Maybe it won't handle something more convoluted in the body of
the constructor, but at least mem-initializers will be warned. One only needs
to keep track which members have been initialized already, and if we use one
before it has been initialized, then warn. No dataflow needed. 

Alternatively, the C++ front-end could create an uninitialized variable for
each member variable. Initialize those, then, at the very end of the
constructor, assigned each clone variable to the appropriate member. This will
also enabled uninitialized warnings with the current infrastructure and it will
work in the body of the constructor.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2010-02-24 20:22 -------
(In reply to comment #11)
> (In reply to comment #8)
> > What else could it be than a pointer?  It might be possible to mark it somehow
> > so that the middle end knows to consider the referent uninitialized.
> 
> This is because (this) must be allocated outside the constructor, isn't it? 
> 
> Is there nothing pointed by this that could be initialized before calling the
> constructor?
> 
> > Incidentally, perhaps we should mark the this parameter as __restrict...
> 
> Yes, with the new __restrict support, this may bring some benefit. Should I
> open a PR about this?

I don't see how this would be correct (or useful).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[manu at gcc dot gnu dot org]

------- Comment #13 from manu at gcc dot gnu dot org  2010-02-24 20:14 -------
(In reply to comment #9)
> 
> I'd close this one as WONTFIX or mark it as dup of a "do uninitialized
> variable warnings for memory".
> 

Please no, this perhaps could still be implemented in the C++ front-end for
this particular case. Maybe there is a way to keep track of which initializers
have been seen already and which members are not initialized elsewhere.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[jason at gcc dot gnu dot org]

------- Comment #12 from jason at gcc dot gnu dot org  2010-02-24 20:12 -------
(In reply to comment #11)
> (In reply to comment #8)
> > What else could it be than a pointer?  It might be possible to mark it somehow
> > so that the middle end knows to consider the referent uninitialized.
> 
> This is because (this) must be allocated outside the constructor, isn't it? 

Yes.  The storage for the object is allocated separately, either on the stack
or on the heap, and then the constructor is called to initialize it.

> Is there nothing pointed by this that could be initialized before calling the
> constructor?

Nothing.

> > Incidentally, perhaps we should mark the this parameter as __restrict...
> 
> Yes, with the new __restrict support, this may bring some benefit. Should I
> open a PR about this?

Sure.  Only in constructors, of course.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[manu at gcc dot gnu dot org]

------- Comment #11 from manu at gcc dot gnu dot org  2010-02-24 19:44 -------
(In reply to comment #8)
> What else could it be than a pointer?  It might be possible to mark it somehow
> so that the middle end knows to consider the referent uninitialized.

This is because (this) must be allocated outside the constructor, isn't it? 

Is there nothing pointed by this that could be initialized before calling the
constructor?

> Incidentally, perhaps we should mark the this parameter as __restrict...

Yes, with the new __restrict support, this may bring some benefit. Should I
open a PR about this?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[bart dot vanassche at gmail dot com]

------- Comment #10 from bart dot vanassche at gmail dot com  2010-02-24 19:10 -------
(In reply to comment #9)
> I think there is no reasonable way to get reliable uninitialized variable
> warnings for incoming pointed-to memory.  The only way we can warn here
> is by inlining the constructor into the caller to see either a static
> variable or the memory allocation.

Why would inlining the constructor be necessary ? Does this mean that it is not
possible to mark member variables as uninitialized in gcc ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2010-02-24 18:04 -------
(In reply to comment #8)
> What else could it be than a pointer?  It might be possible to mark it somehow
> so that the middle end knows to consider the referent uninitialized.
> 
> Incidentally, perhaps we should mark the this parameter as __restrict...
> 
> It does seem reasonable for the front end to detect uses of a member in a
> previous mem-initializer, though that wouldn't handle uses in the body.

I think there is no reasonable way to get reliable uninitialized variable
warnings for incoming pointed-to memory.  The only way we can warn here
is by inlining the constructor into the caller to see either a static
variable or the memory allocation.

But this all boils down to the middle-end not doing uninitialized variable
warnings for memory at all.

I'd close this one as WONTFIX or mark it as dup of a "do uninitialized
variable warnings for memory".

Note that for unrelated reasons we had the idea of introducing a way to
tell the middle-end that previous content of memory becomes undefined,
sort-of adding an assignment from an undefined value like

  A = <error-mark>;

for the reason to preserve aggregate lifetime information after BIND
expression lowering.  The above might also be used carefully in
constructors to mark pieces that the constructor is supposed to initialize
as having undefined content.  Well - if the language standard allows
this.

Of course using <error-mark> is just a random (and probably bad) idea.
Introducing a SSA name default definition for A (even though not of
register type) might be another trick.

The frontend could also use the above at the end of destructors to help
dead code elimination.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[jason at gcc dot gnu dot org]

------- Comment #8 from jason at gcc dot gnu dot org  2010-02-24 16:43 -------
What else could it be than a pointer?  It might be possible to mark it somehow
so that the middle end knows to consider the referent uninitialized.

Incidentally, perhaps we should mark the this parameter as __restrict...

It does seem reasonable for the front end to detect uses of a member in a
previous mem-initializer, though that wouldn't handle uses in the body.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[manu at gcc dot gnu dot org]

------- Comment #7 from manu at gcc dot gnu dot org  2010-02-24 12:59 -------
This usage could be warned in the front-end. Specially because the SSA form
looks like:

S::S() (struct SD.2093 * const thisD.2102)
{
  intD.2 D.2131;

  # BLOCK 2, starting at line 6
  # PRED: ENTRY (fallthru)
  [pr19808.C : 6:20] D.2131_2 = thisD.2102_1(D)->jD.2096;
  [pr19808.C : 6:20] thisD.2102_1(D)->iD.2095 = D.2131_2;
  [pr19808.C : 6:20] thisD.2102_1(D)->jD.2096 = 1;
  [pr19808.C : 6:23] return;
  # SUCC: EXIT
}

Since *this is a pointer parameter (why?), the middle-end cannot know that j is
uninitialized.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2010-02-24 12:46 -------
*** Bug 43163 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bart dot vanassche at gmail
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[manu at gcc dot gnu dot org]

------- Comment #5 from manu at gcc dot gnu dot org  2008-07-21 14:30 -------
*** Bug 36866 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pentek dot imre at gmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[myselfhimself at free dot fr]

------- Comment #4 from myselfhimself at free dot fr  2007-12-04 21:03 -------
*** Bug 34307 has been marked as a duplicate of this bug. ***


-- 

myselfhimself at free dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |34307
              nThis|                            |
                 CC|                            |myselfhimself at free dot fr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

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

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-02 12:58 -------
*** Bug 26072 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at agmk dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808