public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/96074] New: Associative containers never propagate allocator on copy assignment
@ 2020-07-06 12:00 alisdairm at me dot com
2020-07-06 12:10 ` [Bug libstdc++/96074] " redi at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: alisdairm at me dot com @ 2020-07-06 12:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96074
Bug ID: 96074
Summary: Associative containers never propagate allocator on
copy assignment
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Created attachment 48834
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48834&action=edit
Validate allocator propagation for all containers
The attached test driver is a simple validation that each container correctly
propgates allocators, given all 16 possible permutations of the traits.
All containers pass with the exception of the 4 associative containers that
each ignore the propagate_on_container_copy_assigment trait.
Note the test driver is slow to build as it instantiates a lot of templates.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/96074] Associative containers never propagate allocator on copy assignment
2020-07-06 12:00 [Bug libstdc++/96074] New: Associative containers never propagate allocator on copy assignment alisdairm at me dot com
@ 2020-07-06 12:10 ` redi at gcc dot gnu.org
2021-12-01 15:31 ` redi at gcc dot gnu.org
2021-12-01 15:46 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2020-07-06 12:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96074
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-07-06
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/96074] Associative containers never propagate allocator on copy assignment
2020-07-06 12:00 [Bug libstdc++/96074] New: Associative containers never propagate allocator on copy assignment alisdairm at me dot com
2020-07-06 12:10 ` [Bug libstdc++/96074] " redi at gcc dot gnu.org
@ 2021-12-01 15:31 ` redi at gcc dot gnu.org
2021-12-01 15:46 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-01 15:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96074
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Keywords| |wrong-code
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Off topic, in your test you have:
// needed for gcc
template <typename U>
struct rebind { using other = allocator<U, COPY, MOVE, SWAP, false>; };
Isn't that needed always? allocator_traits can only provide a default rebind
for an allocator "of the form Alloc<U, Args>, where Args is zero or more type
arguments". Your non-type template arguments prevent that from working.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/96074] Associative containers never propagate allocator on copy assignment
2020-07-06 12:00 [Bug libstdc++/96074] New: Associative containers never propagate allocator on copy assignment alisdairm at me dot com
2020-07-06 12:10 ` [Bug libstdc++/96074] " redi at gcc dot gnu.org
2021-12-01 15:31 ` redi at gcc dot gnu.org
@ 2021-12-01 15:46 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-01 15:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96074
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|ASSIGNED |RESOLVED
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Your test allocator has a bug. You do not override the is_always_equal trait
from the base class, which means you inherit std::allocator<T>::is_always_equal
which is defined to be std::true_type. So the associative containers elide the
propagation:
if (_Alloc_traits::_S_propagate_on_copy_assign())
{
auto& __this_alloc = this->_M_get_Node_allocator();
auto& __that_alloc = __x._M_get_Node_allocator();
if (!_Alloc_traits::_S_always_equal()
&& __this_alloc != __that_alloc)
{
// Replacement allocator cannot free existing storage, we
need
// to erase nodes first.
clear();
std::__alloc_on_copy(__this_alloc, __that_alloc);
}
}
If I add this to the primary template and the partial specialization then all
tests pass (including the commented-out one for std::stringbuf):
using is_always_equal = std::false_type;
You have been bitten by LWG 3170: https://cplusplus.github.io/LWG/issue3170
std::allocator<T>::is_always_equal is deprecated for precisely this reason
(it's a very annoying trap) but it's still there in C++20, so you need to
override it.
Closing, as the libstdc++ containers are already correct.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-12-01 15:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-06 12:00 [Bug libstdc++/96074] New: Associative containers never propagate allocator on copy assignment alisdairm at me dot com
2020-07-06 12:10 ` [Bug libstdc++/96074] " redi at gcc dot gnu.org
2021-12-01 15:31 ` redi at gcc dot gnu.org
2021-12-01 15:46 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).