* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
@ 2021-06-02 2:57 ` ppalka at gcc dot gnu.org
2021-06-02 9:35 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-06-02 2:57 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
2021-06-02 2:57 ` [Bug libstdc++/100863] " ppalka at gcc dot gnu.org
@ 2021-06-02 9:35 ` redi at gcc dot gnu.org
2021-06-02 10:50 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-02 9:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
2021-06-02 2:57 ` [Bug libstdc++/100863] " ppalka at gcc dot gnu.org
2021-06-02 9:35 ` redi at gcc dot gnu.org
@ 2021-06-02 10:50 ` redi at gcc dot gnu.org
2021-06-02 12:33 ` cvs-commit at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-02 10:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (2 preceding siblings ...)
2021-06-02 10:50 ` redi at gcc dot gnu.org
@ 2021-06-02 12:33 ` cvs-commit at gcc dot gnu.org
2021-06-02 12:59 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-02 12:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (3 preceding siblings ...)
2021-06-02 12:33 ` cvs-commit at gcc dot gnu.org
@ 2021-06-02 12:59 ` redi at gcc dot gnu.org
2021-06-02 13:00 ` redi at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-02 12:59 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (4 preceding siblings ...)
2021-06-02 12:59 ` redi at gcc dot gnu.org
@ 2021-06-02 13:00 ` redi at gcc dot gnu.org
2021-07-19 11:47 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-02 13:00 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (5 preceding siblings ...)
2021-06-02 13:00 ` redi at gcc dot gnu.org
@ 2021-07-19 11:47 ` redi at gcc dot gnu.org
2021-07-20 15:23 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-07-19 11:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (6 preceding siblings ...)
2021-07-19 11:47 ` redi at gcc dot gnu.org
@ 2021-07-20 15:23 ` cvs-commit at gcc dot gnu.org
2021-07-20 15:27 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-20 15:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (7 preceding siblings ...)
2021-07-20 15:23 ` cvs-commit at gcc dot gnu.org
@ 2021-07-20 15:27 ` redi at gcc dot gnu.org
2021-10-12 19:41 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-07-20 15:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (8 preceding siblings ...)
2021-07-20 15:27 ` redi at gcc dot gnu.org
@ 2021-10-12 19:41 ` cvs-commit at gcc dot gnu.org
2021-10-12 19:41 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-10-12 19:41 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (9 preceding siblings ...)
2021-10-12 19:41 ` cvs-commit at gcc dot gnu.org
@ 2021-10-12 19:41 ` cvs-commit at gcc dot gnu.org
2021-11-26 16:34 ` cvs-commit at gcc dot gnu.org
2021-11-26 16:34 ` cvs-commit at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-10-12 19:41 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (10 preceding siblings ...)
2021-10-12 19:41 ` cvs-commit at gcc dot gnu.org
@ 2021-11-26 16:34 ` cvs-commit at gcc dot gnu.org
2021-11-26 16:34 ` cvs-commit at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-26 16:34 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
2021-06-01 20:30 [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
` (11 preceding siblings ...)
2021-11-26 16:34 ` cvs-commit at gcc dot gnu.org
@ 2021-11-26 16:34 ` cvs-commit at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-26 16:34 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread