http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Joost VandeVondele from comment #14)
(In reply to Jonathan Wakely from comment #10)
No, you're right, that's a different issue. I think we've just been relying
on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Dmitry Vyukov dvyukov at google dot com changed:
What|Removed |Added
CC||dvyukov at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org ---
This reminds me http://llvm.org/bugs/show_bug.cgi?id=17066
Do you have this problem with clang's tsan?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #2 from Oleg Smolsky oleg at smolsky dot net ---
Unfortunately, I cannot repro with Clang (we use gcc48 with sysroot, and
I failed to get Clang to latch onto that STL. It only discovers the
system's STL)
I can try to come up with a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org ---
I can try to come up with a minimal test case... Yet, I cannot imagine
that the following would ever work with TSan:
typedef int _Atomic_word;
It does not matter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Oleg Smolsky from comment #0)
in ...gcc/include/c++/4.8.x-google/x86_64-unknown-linux/bits/atomic_word.h
typedef int _Atomic_word;
Should this be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
I realise that, but the general point is still valid: for race detectors to
understand the atomic updates in the library they library needs to be compiled
with the race detector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #6)
tsan as well, but the point is till ...
s/till/still/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #6)
I realise that, but the general point is still valid: for race detectors to
understand the atomic updates in the library they library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #9 from Oleg Smolsky oleg at smolsky dot net ---
So, let me see if I understand. The case in question is _M_add_ref_lock() :
template
inline void
_Sp_counted_base_S_atomic::
_M_add_ref_lock()
{
// Perform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org ---
But only if you re-compile stdlibc++ with tsan,
It's libstdc++ not stdlibc++, I don't know why everyone gets that wrong :-)
Sorry (I usually get it right) :)
Anyway, this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org ---
No, you're right, that's a different issue. I think we've just been relying on
loads of (correctly-aligned) _Atomic_word being atomic, although that's not
going to keep tsan happy!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #11 from Kostya Serebryany kcc at gcc dot gnu.org ---
_Atomic_word __count = _M_use_count; the read
Interesting.
We haven't seen these (we don't use this implementation of shared_ptr).
I think the code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #12 from Oleg Smolsky oleg at smolsky dot net ---
Hey Kostya, should I try suppressing the report using the function name? Would
it work in optimized builds that have inlining?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #13 from Kostya Serebryany kcc at gcc dot gnu.org ---
(In reply to Oleg Smolsky from comment #12)
Hey Kostya, should I try suppressing the report using the function name?
Would it work in optimized builds that have inlining?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC|
16 matches
Mail list logo
