https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
François Dumont changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #12 from François Dumont ---
Author: fdumont
Date: Mon Sep 29 21:22:17 2014
New Revision: 215693
URL: https://gcc.gnu.org/viewcvs?rev=215693&root=gcc&view=rev
Log:
2014-09-29 François Dumont
PR libstdc++/62313
* include/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #11 from Dmitry Vyukov ---
Just test it with
g++ test.cc -Wall -lpthread -fsanitize=thread -pie -fPIE -D_GLIBCXX_DEBUG -g
-O2
There is nothing else I can do on top of that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
François Dumont changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #9 from Dmitry Vyukov ---
Don't forget about destructor -- the iterator must be removed from list before
it destruction starts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #8 from Jonathan Wakely ---
It might be possible to solve using the base-from-member idiom so that
_M_current is set before the iterator is added to the collection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #7 from François Dumont ---
ok, looks like Jonathan it pretty sure it is a bug, I am going to take a closer
look at it.
When I said that you would have the same issue with all versions of Standard
lib I meant with all version of libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #6 from Dmitry Vyukov ---
> The tests for the debug mode don't generally involve threads, so that isn't
> likely to help.
Then you can run any heavily multithreaded program that extensively uses stl
and is currently race-free. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #5 from Jonathan Wakely ---
(In reply to François Dumont from comment #4)
> For me there is no bug. Standard containers are known to not be thread safe.
No, containers are known to be thread-safe, when used correctly.
> I don't know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #4 from François Dumont ---
For me there is no bug. Standard containers are known to not be thread safe. I
don't know what Standard points are talking about it but what I consider as
valid was iterating through the container from dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #2 from Dmitry Vyukov ---
The additional thread only touches iter, and the main thread does not touch
iter nor invalidate it. So there is nothing to protect here. The program does
not contain data races per se.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313
--- Comment #1 from Andrew Pinski ---
You don't protect either the iterators or the list when touching it so I don't
think this is a bug. If they truly independent lists and that was causing
issues, then yes there would be an issue.
13 matches
Mail list logo
