https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #13 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> I see this on power 9 fedora 37 (glibc-2.36) but not on power 8 centos 7.9
> (glibc-2.17).
Also seen on power 9 rhel 9 (glibc-2.34-60.el9.ppc64le)
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #11 from Jonathan Wakely ---
The test looks like this:
#include
#include
int main()
{
typedef int value_type;
typedef __gnu_cxx::throw_allocator_random allocator_type;
try { __gnu_test::check_deallocate_null(); }
catch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> Should have said "only with -std=c++17" (and later, of course).
Actually, that's wrong, *only* with C++17, not earlier *or* later.
So the further changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> With -std=c++14 there's no crash, with -std=c++17,
Should have said "only with -std=c++17" (and later, of course).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #8 from Jonathan Wakely ---
With -std=c++14 there's no crash, with -std=c++17, so that confirms it's
something related to copy elision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #7 from Jonathan Wakely ---
When the function returns the iterator's destructor should detach itself from
the sequence's list of iterators, so that it doesn't outlive the stack frame
containing the iterator.
The commit that caused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #6 from Tulio Magno Quites Machado Filho ---
Let me elaborate my previous comment...
When initializing the object at 0x100414c8, one of its members points to an
address in the stack (0x7fffe8f8).
All these functions return and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #5 from Tulio Magno Quites Machado Filho ---
(In reply to Jonathan Wakely from comment #3)
> I wonder if we have a static destructor ordering problem.
I'm afraid the issue is happening earlier, when these iterators are being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #4 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #2)
> r2 is the toc pointer, so having it 0 is weird.
> Looking at glibc-2.36-10.fc37 (not sure if you are using a different one), I
glibc-2.36-9.fc37.ppc64le
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #3 from Jonathan Wakely ---
I wonder if we have a static destructor ordering problem.
The libstdc++ test code uses a local static std::map, which will be
constructed on first use and destroyed on exit. When built with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #2 from Jakub Jelinek ---
r2 is the toc pointer, so having it 0 is weird.
Looking at glibc-2.36-10.fc37 (not sure if you are using a different one), I
see
0005b560 <__run_exit_handlers>:
5b560: 21 00 4c 3c addis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #1 from Jonathan Wakely ---
Tulio found out that __gnu_debug::_Safe_iterator_base::_M_reset() is
overwriting the stack where r2 (TOC pointer) was saved by __run_exit_handlers()
(at address 0x7fffe8e8). This function was
14 matches
Mail list logo
