[Bug libstdc++/100863] New: 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[Bug libstdc++/100863] New: 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[ppalka at gcc dot gnu.org]

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

            Bug ID: 100863
           Summary: 23_containers/unordered_{map,set}/allocator/default_in
                    it.cc still fail at runtime even after r12-1153
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

These two tests still fail at runtime even after the r12-1153 fix for PR65816. 
The tests fail at runtime when compiled with Clang.

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[ppalka at gcc dot gnu.org]

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

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The problem seems to be that default initialization of an unordered_map/set
only default initializes the allocator object rather than value initializing
it.  This means the allocator's state doesn't get implicitly zeroed out, which
causes the assert inside test01() to fail.  A potential fix is to make
_Hashtable_alloc's default constructor value initialize the allocator object:

--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -1856,7 +1856,10 @@ namespace __detail
       using __buckets_alloc_traits =
std::allocator_traits<__buckets_alloc_type>;
       using __buckets_ptr = __node_base_ptr*;

-      _Hashtable_alloc() = default;
+      _Hashtable_alloc() noexcept(noexcept(__ebo_node_alloc()))
+      : __ebo_node_alloc()
+      { }
+
       _Hashtable_alloc(const _Hashtable_alloc&) = default;
       _Hashtable_alloc(_Hashtable_alloc&&) = default;

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-06-02
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Hmm, this looks very familiar, I thought that was fixed already.

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Do we ever want the _Hashtable_ebo_helper<N, T> to *not* value-init its T
subobject? I think we should do the value-init in _Hashtable_ebo_helper
instead.

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 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 libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Done

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
            Version|11.0                        |12.0

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|RESOLVED                    |REOPENED

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
My fix causes a regression:

#include <unordered_set>

template <typename Tp>
  struct Allocator
  {
    using value_type = Tp;

    Allocator(int) noexcept { }

    template <class T>
      Allocator(const Allocator<T>&) { }

    Tp *allocate(std::size_t n)
    { return std::allocator<Tp>().allocate(n); }

    void deallocate(Tp *p, std::size_t n)
    { std::allocator<Tp>().deallocate(p, n); }
  };

using Set = std::unordered_set<int, std::hash<int>, std::equal_to<int>,
Allocator<int>>;

static_assert( ! std::is_default_constructible<Set>::value, "" );

The standard doesn't require the trait to be true, but it was (because we
defined the default constructors as defaulted all the way down to the EBO
helper). With the change above, the EBO helper for an empty class does:

  _Hashtable_ebo_helper() noexcept(noexcept(_Tp())) : _Tp() { }

which is ill-formed now, not implicitly deleted.

I have a patch to make it use [[no_unique_address]], so we can default it
again.

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:89ec3b67dbe856a447d068b053bc19559f136f43

commit r12-2415-g89ec3b67dbe856a447d068b053bc19559f136f43
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jul 20 15:20:41 2021 +0100

    libstdc++: fix is_default_constructible for hash containers [PR 100863]

    The recent change to _Hashtable_ebo_helper for this PR broke the
    is_default_constructible trait for a hash container with a non-default
    constructible allocator. That happens because the constructor needs to
    be user-provided in order to initialize the member, and so is not
    defined as deleted when the type is not default constructible.

    By making _Hashtable derive from _Enable_special_members we can ensure
    that the default constructor for the std::unordered_xxx containers is
    deleted when it would be ill-formed. This makes the trait give the
    correct answer.

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

    libstdc++-v3/ChangeLog:

            PR libstdc++/100863
            * include/bits/hashtable.h (_Hashtable): Conditionally delete
            default constructor by deriving from _Enable_special_members.
            * testsuite/23_containers/unordered_map/cons/default.cc: New test.
            * testsuite/23_containers/unordered_set/cons/default.cc: New test.

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Re-fixed.

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 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 libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 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:10c0df1048fdb6404328d4966a3737d4f784c48f

commit r11-9140-g10c0df1048fdb6404328d4966a3737d4f784c48f
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jul 20 15:20:41 2021 +0100

    libstdc++: fix is_default_constructible for hash containers [PR 100863]

    The recent change to _Hashtable_ebo_helper for this PR broke the
    is_default_constructible trait for a hash container with a non-default
    constructible allocator. That happens because the constructor needs to
    be user-provided in order to initialize the member, and so is not
    defined as deleted when the type is not default constructible.

    By making _Hashtable derive from _Enable_special_members we can ensure
    that the default constructor for the std::unordered_xxx containers is
    deleted when it would be ill-formed. This makes the trait give the
    correct answer.

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

    libstdc++-v3/ChangeLog:

            PR libstdc++/100863
            * include/bits/hashtable.h (_Hashtable): Conditionally delete
            default constructor by deriving from _Enable_special_members.
            * testsuite/23_containers/unordered_map/cons/default.cc: New test.
            * testsuite/23_containers/unordered_set/cons/default.cc: New test.

    (cherry picked from commit 89ec3b67dbe856a447d068b053bc19559f136f43)

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 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)

[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153

[cvs-commit at gcc dot gnu.org]

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

--- 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:5c86e63cb0383a38ec3dea24e9b3fe2f6e312057

commit r10-10305-g5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jul 20 15:20:41 2021 +0100

    libstdc++: fix is_default_constructible for hash containers [PR 100863]

    The recent change to _Hashtable_ebo_helper for this PR broke the
    is_default_constructible trait for a hash container with a non-default
    constructible allocator. That happens because the constructor needs to
    be user-provided in order to initialize the member, and so is not
    defined as deleted when the type is not default constructible.

    By making _Hashtable derive from _Enable_special_members we can ensure
    that the default constructor for the std::unordered_xxx containers is
    deleted when it would be ill-formed. This makes the trait give the
    correct answer.

    This backport to gcc-10 includes the fix for PR 101583.

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

    libstdc++-v3/ChangeLog:

            PR libstdc++/100863
            * include/bits/hashtable.h (_Hashtable): Conditionally delete
            default constructor by deriving from _Enable_default_constructor.
            Construct that base-class explicitly in all non-forwarding,
            non-defaulted constructors.
            * testsuite/23_containers/unordered_map/cons/default.cc: New test.
            * testsuite/23_containers/unordered_set/cons/default.cc: New test.

    (cherry picked from commit 89ec3b67dbe856a447d068b053bc19559f136f43)