[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5c86e63cb0383a38ec3dea24e9b3fe2f6e312057 commit r10-10305-g5c86e63cb0383a38ec3dea24e9b3fe2f6e312057 Author: Jonathan Wakely 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 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)
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cc56c03a7a7f034f98a835dcb7047ad3d2ace6bd commit r10-10304-gcc56c03a7a7f034f98a835dcb7047ad3d2ace6bd Author: Jonathan Wakely 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:10c0df1048fdb6404328d4966a3737d4f784c48f commit r11-9140-g10c0df1048fdb6404328d4966a3737d4f784c48f Author: Jonathan Wakely 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:573c2ffd3cacde5c54605eb0d8b312d22594f7fa commit r11-9139-g573c2ffd3cacde5c54605eb0d8b312d22594f7fa Author: Jonathan Wakely 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Re-fixed.
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:89ec3b67dbe856a447d068b053bc19559f136f43 commit r12-2415-g89ec3b67dbe856a447d068b053bc19559f136f43 Author: Jonathan Wakely 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
Jonathan Wakely 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 ---
My fix causes a regression:
#include
template
struct Allocator
{
using value_type = Tp;
Allocator(int) noexcept { }
template
Allocator(const Allocator&) { }
Tp *allocate(std::size_t n)
{ return std::allocator().allocate(n); }
void deallocate(Tp *p, std::size_t n)
{ std::allocator().deallocate(p, n); }
};
using Set = std::unordered_set, std::equal_to,
Allocator>;
static_assert( ! std::is_default_constructible::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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Done
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f8f0193b5b83f6e85d65015e79c803295baf5166 commit r12-1163-gf8f0193b5b83f6e85d65015e79c803295baf5166 Author: Jonathan Wakely 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #3 from Jonathan Wakely --- Do we ever want the _Hashtable_ebo_helper 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-06-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #1 from Patrick Palka ---
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;
