This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/66742] abort on sorting list with custom compiler that is not stateless
- From: "mdiluzio at feralinteractive dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 03 Jul 2015 08:13:59 +0000
- Subject: [Bug libstdc++/66742] abort on sorting list with custom compiler that is not stateless
- Auto-submitted: auto-generated
- References: <bug-66742-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742
--- Comment #3 from Marc Di Luzio <mdiluzio at feralinteractive dot com> ---
Created attachment 35901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35901&action=edit
main.ii
Updating with a valid ==/!= operator pair and state handling, apologies for the
original bad test case.
gcc output is the same verbatim as above.
However, sort still aborts with any allocator that provides ==/!= operators
based on internal state that is non-default.
sort contains a default constructed list __carry, which will have a different
allocator instance to the parent list if an allocator was passed in on
construction -
list.tcc:402
list __carry;
__carry is then spliced with the parent list -
list.tcc:409
__carry.splice(__carry.begin(), *this, begin());
A check then occurs if the two allocators are equal -
stl_list.h:1374
if (this != &__x)
_M_check_equal_allocators(__x);
allocator.h:188
static bool
_S_do_it(const _Alloc& __one, const _Alloc& __two)
{ return __one != __two; }
This final check will fail if the != operator for the allocator is dependent on
internal state comparison, which has differs from the default.
This appears to be incorrect, unless I'm misunderstanding the purpose of the
==/!= operators for allocators?
If this is still considered an issue, I would suggest that __carry be copy
constructed.