Bug 30111 - Value-initialization of POD base class doesn't initialize members
Summary: Value-initialization of POD base class doesn't initialize members
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.1.1
: P3 normal
Target Milestone: ---
Assignee: Jason Merrill
Keywords: wrong-code
: 32141 (view as bug list)
Depends on:
Reported: 2006-12-07 17:51 UTC by Jonathan Wakely
Modified: 2022-05-19 16:39 UTC (History)
6 users (show)

See Also:
Known to work:
Known to fail: 4.2.0 4.1.1 3.4.3 3.3.4
Last reconfirmed: 2009-02-11 05:35:35


Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Wakely 2006-12-07 17:51:37 UTC
#include <iostream>

int main()
    struct pod {
        int i;

    struct inherit : pod {
        inherit() : pod() {}

    struct compose {
        compose() : p() {}
        pod p;

    inherit i;
    compose c;

    std::cout << i.i << std::endl;
    std::cout << c.p.i << std::endl;

In both cases the pod object is explicitly value-initialized, which according to 8.5para5 means that "every non-static data member ... is value-initialized"

compose::pod::i is value-initialised, inherit::i is not.  This can be seen from the values printed out for i.i and by using Purify.

Same result with GCC 4.1.1, 3.4.3, 3.3.4 on Solaris 9, GCC 3.4.3 on AIX 5/3

Valgrind is being weird so I can't test it on Linux, butI don't think it's platform-dependent.
Comment 1 Jonathan Wakely 2006-12-07 18:03:26 UTC
Values printed out confirm it on Linux for 3.3.5 20050117 (prerelease) (SUSE Linux), and official FSF 3.4.3, 4.0.1, 4.0.2, 4.1.1

N.B. I meant AIX 5.3, not 5/3
Comment 2 Richard Biener 2006-12-08 07:27:47 UTC
As compose is not POD it initializes p in the constructor.  For inherit the constructor of p is called which - surprise - as a POD constructor does nothing.
Comment 3 Andrew Pinski 2006-12-08 07:34:47 UTC
(In reply to comment #2)
> As compose is not POD it initializes p in the constructor.  For inherit the
> constructor of p is called which - surprise - as a POD constructor does
> nothing.

Actually read the standard, it does, see 8.5/7 and 8.5/5 the second part about default initializer.
Comment 4 Jonathan Wakely 2006-12-08 10:36:00 UTC
Richard, there's no difference between pod() and p() in this case, both are value-initialisations of a POD class, therefore all non-static data members should be value-initialised.  I cited 8.5p5 for good reason :)

Sun CC 6.1 and 8 and IBM xlC 6 get this right.
Comment 5 Gabriel Dos Reis 2006-12-30 19:40:22 UTC
Thsi is indeed a bug in g++.
the pod() in inherit() is a value-initialization, not a call to 
Comment 6 Andrew Pinski 2007-06-10 02:18:49 UTC
*** Bug 32141 has been marked as a duplicate of this bug. ***
Comment 7 Jonathan Wakely 2007-06-18 01:36:55 UTC
Confirmed on x86-linux, sparc-solaris and ppc-AIX so I've removed the Target.

Also verified that valgrind shows the uninitialised memory reads.

This bug breaks common idioms like:

template <typename A, typename B>
  struct compressed_pair : A {
    compressed_pair() : A(), second_() { }
    A& first() { return *this; }
    B& second() { return second_; }
    B second_;

Comment 8 Richard Biener 2008-02-04 16:06:36 UTC
Jason is this the same issue as PR33916 you fixed?  (Your fix didn't change
the outcome of this PR though)
Comment 9 Jason Merrill 2009-02-11 22:38:57 UTC
Subject: Bug 30111

Author: jason
Date: Wed Feb 11 22:38:37 2009
New Revision: 144112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144112
        PR c++/30111
        * init.c (build_value_init_noctor): Split out from...
        (build_value_init): ...here.
        (expand_aggr_init_1): Handle value-initialization.
        * cp-tree.h: Add declaration.
        * class.c (type_has_user_provided_constructor):
        Handle non-class arguments.


Comment 10 Jason Merrill 2009-02-11 22:50:29 UTC
Fixed for 4.4.
Comment 11 Jackie Rosen 2014-02-16 10:02:44 UTC Comment hidden (spam)