[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|12.2|12.0 --- Comment #21 from Jonathan Wakely --- This was fixed for 12.1
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jakub Jelinek changed: What|Removed |Added Target Milestone|12.0|12.2 --- Comment #20 from Jakub Jelinek --- GCC 12.1 is being released, retargeting bugs to GCC 12.2.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #19 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1e7a269856fd67aff78ac874bec96d31a54b2fd9 commit r12-4873-g1e7a269856fd67aff78ac874bec96d31a54b2fd9 Author: Jonathan Wakely Date: Tue Nov 2 10:21:01 2021 + libstdc++: Fix regression in std::list::sort [PR66742] The standard does not require const-correct comparisons in list::sort. libstdc++-v3/ChangeLog: PR libstdc++/66742 * include/bits/list.tcc (list::sort): Use mutable iterators for comparisons. * include/bits/stl_list.h (_Scratch_list::_Ptr_cmp): Likewise. * testsuite/23_containers/list/operations/66742.cc: Check non-const comparisons.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #18 from Jonathan Wakely ---
My fix caused a regression for this (IMHO dumb) case:
#include
struct X {
bool operator<(X&) /* non-const */ { return false; }
};
struct Cmp {
bool operator()(X&, X&) /* non-const */ { return false; }
};
int main() {
std::list l;
l.sort();
Cmp c;
l.sort(c);
}
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Jonathan Wakely --- Fixed for GCC 12.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #16 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ff7793bea465019683b3a07d7ffceb6eae22def5 commit r12-4082-gff7793bea465019683b3a07d7ffceb6eae22def5 Author: Jonathan Wakely Date: Tue May 25 14:33:15 2021 +0100 libstdc++: Allow stateful allocators in std::list::sort [PR 66742] The temporary lists used by std::list::sort are default constructed, which means they use default constructed allocators. The sort operation is defined in terms of merge and splice operations, which have undefined behaviour (and abort) if the allocators do not compare equal. This means it is not possible to sort a list that uses an allocator that compares unequal to an default constructed allocator. The solution is to avoid using temporary std::list objects at all. We do not need to be able to allocate memory because no nodes are allocated, only spliced from one list to another. That means the temporary lists don't need an allocator at all, so whether it would compare equal doesn't matter. Instead of temporary std::list objects, we can just use a collection of _List_node_base objects that nodes can be spliced onto as needed. Those objects are wrapped in a _Scratch_list type that implements the splicing and merging operations used by list::sort. We also don't need to update the list size during the sort, because sorting doesn't alter the number of nodes. Although we move nodes in and out of the scratch lists, at the end of the function all nodes are back in the original std::list and the scratch lists are empty. So for the cxx11 ABI we can avoid the _M_size modifications usually done when splicing nodes. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/66742 * include/bits/list.tcc (list::sort()): Use _Scratch_list objects for splicing and merging. (list::sort(StrictWeakOrdering)): Likewise. * include/bits/stl_list.h (__detail::_Scratch_list): New type. * src/c++98/list.cc (_List_node_base::_M_transfer): Add assertion for --enable-libstdcxx-debug library. * testsuite/23_containers/list/operations/66742.cc: New test.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Richard Biener changed: What|Removed |Added Target Milestone|11.2|---
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #15 from Jonathan Wakely --- Fixed downstream in my fork: https://gitlab.com/jonathan-wakely/gcc/-/commit/18d78721bf3afaed243252a01a4f4909c17531b2
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jakub Jelinek changed: What|Removed |Added Target Milestone|11.0|11.2 --- Comment #14 from Jakub Jelinek --- GCC 11.1 has been released, retargeting bugs to GCC 11.2.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Alexander Huszagh changed: What|Removed |Added CC||ahuszagh at gmail dot com --- Comment #13 from Alexander Huszagh --- Any chance we can merge the proposed patch on this? This still triggers in GCC-10.2.1, and the proposed patch works if applied to both `sort()` and `sort(cmp)` implementations in `include/bits/list.tcc`. Version Info: gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added Target Milestone|10.0|11.0
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #12 from Jonathan Wakely --- Yes.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #11 from Eric Gallager --- Are you still working on this, Jonathan?
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org --- Comment #10 from Eric Gallager --- (In reply to Jonathan Wakely from comment #7) > A candidate patch has been posted to > https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00217.html > > With that fix your testcase segfaults, because you allocate n bytes not > n*sizeof(Tp). adding "patch" keyword
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #9 from TC --- The ugly fix in Comment #6 should be performant, if, well, ugly. It may be worth considering holding the nodes via a different type. There's no real reason why the temporary holders need to be a `list` or have a copy of the allocator as long as we make sure that everything in there is spliced back into *this when we exit sort() (by exception or normal return). Speaking of exceptions, merge() appears to have exception safety problems. I'll file a separate bug.
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 Jonathan Wakely changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #8 from Jonathan Wakely --- *** Bug 78371 has been marked as a duplicate of this bug. ***
