https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
--- Comment #6 from Leandro Nini ---
Can't reproduce anymore with gcc 13.1.0
Still there in gcc 12.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
--- Comment #5 from Andrew Pinski ---
(In reply to Leandro Nini from comment #2)
> Oh, now I see it, it wasn't that obvious in the first test. But why is the
> compiler allowed to postpone the store after deleting the pointer? Is there
> some un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
--- Comment #4 from Andrew Pinski ---
Here is a reduced testcase without any std::map or otherwise:
```
struct matrix_t
{
int* count;
matrix_t() :
count(new int(1)) {}
matrix_t(const matrix_t& p) :
count(p.count) { ++*count; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
--- Comment #3 from Andrew Pinski ---
Before PRE
[/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_tree.h:1061:28]
__position ={v} {CLOBBER(eol)};
[/app/example.cpp:25:62] _4 = [/app/example.cpp:25:10]
&[/app/example.cpp:25:62]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
--- Comment #2 from Leandro Nini ---
Oh, now I see it, it wasn't that obvious in the first test. But why is the
compiler allowed to postpone the store after deleting the pointer? Is there
some undefined behavior involved here or what?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1
