http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Dmitry Vyukov changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #15 from Kostya Serebryany ---
(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 loads of (correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #13 from Kostya Serebryany ---
(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?
Excellent question!
If you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #12 from Oleg Smolsky ---
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 #11 from Kostya Serebryany ---
> _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 is simply wrong -- it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #10 from Jonathan Wakely ---
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! There's no barrier on t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #9 from Oleg Smolsky ---
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 lock-free add-if-not-zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #8 from Kostya Serebryany ---
(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 needs to be
> compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #7 from Jonathan Wakely ---
(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 #6 from Jonathan Wakely ---
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 enabled. We can update the d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #5 from Kostya Serebryany ---
> > 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 is already docum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #4 from Jonathan Wakely ---
(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 std::atomic ?
No.
(In repl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #3 from Kostya Serebryany ---
> 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 how _Atomic_word is de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #2 from Oleg Smolsky ---
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 minimal test case... Yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #1 from Kostya Serebryany ---
This reminds me http://llvm.org/bugs/show_bug.cgi?id=17066
Do you have this problem with clang's tsan?
16 matches
Mail list logo
