[Bug sanitizer/68338] tsan report error about c++11 static local initialize

2019-05-25 Thread dushistov at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68338

Evgeniy Dushistov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Evgeniy Dushistov  ---
No issues with gcc 8.3.0

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

2015-11-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68338

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |5.2.0

--- Comment #1 from Jonathan Wakely  ---
I can reproduce this with 5.2 but not trunk.

I suspect it's a false positive and libtsan on trunk has been taught to ignore
it.

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

2015-11-13 Thread dushistov at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68338

--- Comment #2 from Evgeniy Dushistov  ---
The problem as I understand assembler in check
that find out is static variable initialized,

clang emit this:

callq  45bdb0 <__tsan_atomic8_load>

while gcc emit 

callq  401260 <__tsan_read1@plt>

[Bug sanitizer/68338] tsan report error about c++11 static local initialize

2015-11-13 Thread dvyukov at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68338

Dmitry Vyukov  changed:

   What|Removed |Added

 CC||dvyukov at google dot com

--- Comment #3 from Dmitry Vyukov  ---
As far as I remember there was a real bug in gcc that it emitted non-atomic
load for static var initialization fast-path (think broken double-checked
locking). This bug should be fixed by now. So if it works with tip gcc, I
propose to close this.