https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910
--- Comment #2 from leon <leonleon77 at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> Seems like this is a bug in the testcase rather than libstdc++.
>
> >exemplifying concurrent destruction of iterator and container
> That seems like a disaster waiting to happen. Because once the container is
> gone, the iterator is also considered gone. If you did this in a normal
> code without threads it would be invalid to do in that order anyways.
I've checked the above with both: Jonathan Wakely and François Dumont. They
appear to agree that it is a bug in libstdc++ debug mode (they have asked me to
submit the bug report).
On the subject of "normal code without threads"... my understanding is that it
is valid to destroy iterator after the container has been destroyed (we are
talking about just dtor as part of the object going out of scope, not
dereferencing iterator in any way).
Jonathan was very kind to provide an example of valid use (unless I
misunderstood it -- he can correct me of course)... :)
This (destroying iterator after the container) is valid:
{
std::set<int>::iterator iter;
{
std::set<int> s;
iter = s.begin();
} // s.~set() runs here
} // iter.~iterator() runs here
... keeping in mind -- the bug is *not* about deref/using the iterator object
-- just destroying it.
