https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-09-26
Ever confirmed|0 |1
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
Nonsense. It's totally fine for an iterator to be destroyed after the container
it referred to has gone:
{
std::set<int>::iterator iter;
{
std::set<int> s;
iter = s.begin();
} // s.~set() runs here
} // iter.~iterator() runs here
The concurrent case is no different. The iterator's destructor does not access
the container in normal mode, and so there is no data race when the two
constructors run concurrently. In debug mode **we** have introduced spooky
action at a distance, whereby the container and iterator modify each other.
**We** are responsible for making that happen correctly and safely, not the
user.
It would be completely absurd to expect users to lock mutexes around
destruction of every iterator to synchronize it with destruction of the
container.
This is a bug.
