[Bug c++/65816] New: Constructor delegation does not perform zero-initialization

[Bug c++/65816] New: Constructor delegation does not perform zero-initialization

[dyp-cpp at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

            Bug ID: 65816
           Summary: Constructor delegation does not perform
                    zero-initialization
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dyp-cpp at gmx dot net

In the following program, I expect the object `t` to be zero-initialized via
constructor delegation. Clang++ does this, but g++ 6.0 2015-04-20 does not.

-----------------------------

struct test
{
    int m;

    test() = default;
    test(int) : test() {}
};

#include <iostream>

int main()
{
    test t(0);
    std::cout << t.m;
}

-----------------------------

While C++14 IS [class.base.init]p6 is unclear about this, as far as I can tell,
paragraph 7 implies (in the parenthesized clause) that the constructor
`test(int)` is required to value-initialize the object:

> The expression-list or braced-init-list in a mem-initializer is used to initialize the designated subobject (or, in the case of a delegating constructor, the complete class object) according to the initialization rules of 8.5 for direct-initialization.

The class `test` does not have a user-provided default constructor, hence
zero-initialization should be performed as per [dcl.init]p8.2

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-20
     Ever confirmed|0                           |1

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[johelegp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

Johel Ernesto Guerrero Peña <johelegp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johelegp at gmail dot com

--- Comment #6 from Johel Ernesto Guerrero Peña <johelegp at gmail dot com> ---
*** Bug 96790 has been marked as a duplicate of this bug. ***

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[zcsfjvvwjsgomjypri at twzhhq dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

Anon <zcsfjvvwjsgomjypri at twzhhq dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zcsfjvvwjsgomjypri at twzhhq dot c
                   |                            |om

--- Comment #7 from Anon <zcsfjvvwjsgomjypri at twzhhq dot com> ---
Was bitten by this bug today and came to report it, seems like it has already
been reported for some time. Please fix sirs.

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |ppalka at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:ac0bc21bd634a334ba8f323c39a11f01dfdc2aae

commit r12-1153-gac0bc21bd634a334ba8f323c39a11f01dfdc2aae
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Jun 1 12:23:49 2021 -0400

    c++: value-init vs zero-init in expand_aggr_init_1 [PR65816]

    In the case of value-initializing an object of class type T,
    [dcl.init.general]/8 says:

      - if T has either no default constructor ([class.default.ctor]) or
        a default constructor that is user-provided or deleted, then the
        object is default-initialized;
      - otherwise, the object is zero-initialized and ...  if T has a
        non-trivial default constructor, the object is default-initialized;

    But when determining whether to first zero-initialize the object,
    expand_aggr_init_1 incorrectly considers the user-providedness of _all_
    constructors rather than only that of the _default_ constructors.  This
    causes us to skip the zero-initialization step when the class type has a
    defaulted default constructor alongside a user-defined constructor.

    It seems the predicate type_has_non_user_provided_default_constructor
    accurately captures the above rule for when to first perform a
    zero-initialization during value-initialization, so this patch adjusts
    expand_aggr_init_1 to use this predicate instead.

            PR c++/65816

    gcc/cp/ChangeLog:

            * init.c (expand_aggr_init_1): Check
            type_has_non_user_provided_default_constructor instead of
            type_has_user_provided_constructor.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/constexpr-delegating3.C: New test.
            * g++.dg/cpp0x/dc10.C: New test.
            * g++.dg/cpp0x/initlist-base4.C: New test.
            * g++.dg/cpp2a/constexpr-init22.C: New test.

    libstdc++-v3/ChangeLog:

            * testsuite/23_containers/deque/allocator/default_init.cc,
            testsuite/23_containers/forward_list/allocator/default_init.cc,
            testsuite/23_containers/list/allocator/default_init.cc,
            testsuite/23_containers/map/allocator/default_init.cc,
            testsuite/23_containers/set/allocator/default_init.cc,
            testsuite/23_containers/vector/allocator/default_init.cc,
            testsuite/23_containers/vector/bool/allocator/default_init.cc:
            Remove xfail.

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:f8f0193b5b83f6e85d65015e79c803295baf5166

commit r12-1163-gf8f0193b5b83f6e85d65015e79c803295baf5166
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Jun 2 12:34:48 2021 +0100

    libstdc++: Value-initialize objects held by EBO helpers [PR 100863]

    The allocator, hash function and equality function should all be
    value-initialized by the default constructor of an unordered container.
    Do it in the EBO helper, so we don't have to get it right in multiple
    places.

    Signed-off-by: Jonathan Wakely <jwakely@redhat.com>

    libstdc++-v3/ChangeLog:

            PR libstdc++/100863
            PR libstdc++/65816
            * include/bits/hashtable_policy.h (_Hashtable_ebo_helper):
            Value-initialize subobject.
            * testsuite/23_containers/unordered_map/allocator/default_init.cc:
            Remove XFAIL.
            * testsuite/23_containers/unordered_set/allocator/default_init.cc:
            Remove XFAIL.

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |12.0

--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 12.

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:573c2ffd3cacde5c54605eb0d8b312d22594f7fa

commit r11-9139-g573c2ffd3cacde5c54605eb0d8b312d22594f7fa
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Jun 2 12:34:48 2021 +0100

    libstdc++: Value-initialize objects held by EBO helpers [PR 100863]

    The allocator, hash function and equality function should all be
    value-initialized by the default constructor of an unordered container.
    Do it in the EBO helper, so we don't have to get it right in multiple
    places.

    Signed-off-by: Jonathan Wakely <jwakely@redhat.com>

    libstdc++-v3/ChangeLog:

            PR libstdc++/100863
            PR libstdc++/65816
            * include/bits/hashtable_policy.h (_Hashtable_ebo_helper):
            Value-initialize subobject.
            * testsuite/23_containers/unordered_map/allocator/default_init.cc:
            Remove XFAIL.
            * testsuite/23_containers/unordered_set/allocator/default_init.cc:
            Remove XFAIL.

    (cherry picked from commit f8f0193b5b83f6e85d65015e79c803295baf5166)

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:cc56c03a7a7f034f98a835dcb7047ad3d2ace6bd

commit r10-10304-gcc56c03a7a7f034f98a835dcb7047ad3d2ace6bd
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed Jun 2 12:34:48 2021 +0100

    libstdc++: Value-initialize objects held by EBO helpers [PR 100863]

    The allocator, hash function and equality function should all be
    value-initialized by the default constructor of an unordered container.
    Do it in the EBO helper, so we don't have to get it right in multiple
    places.

    Signed-off-by: Jonathan Wakely <jwakely@redhat.com>

    libstdc++-v3/ChangeLog:

            PR libstdc++/100863
            PR libstdc++/65816
            * include/bits/hashtable_policy.h (_Hashtable_ebo_helper):
            Value-initialize subobject.
            * testsuite/23_containers/unordered_map/allocator/default_init.cc:
            Remove XFAIL.
            * testsuite/23_containers/unordered_set/allocator/default_init.cc:
            Remove XFAIL.

    (cherry picked from commit f8f0193b5b83f6e85d65015e79c803295baf5166)