http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
--- Comment #6 from Dmitry Vyukov <dvyukov at google dot com> 2012-11-28 03:56:50 UTC --- There seems to be a similar bug in code generated for function static variables. The fast-path load is a plain load rather than atomic acquire load. On Sat, Nov 24, 2012 at 3:06 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Fri, Nov 23, 2012 at 8:39 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote: >>> That's what llvm does as well. But it inserts a fast path before >>> __cxa_guard_acquire -- acquire-load of the lock word. Doesn't gcc do the >>> same? >> >> Yes, except it isn't __atomic_load_*, but plain memory read. >> _3 = MEM[(char *)&_ZGVZ3foovE1a]; >> if (_3 == 0) >> goto <bb 3>; >> else >> goto <bb 8>; >> >> <bb 8>: >> fast path, whatever; >> >> <bb 3>: >> _5 = __cxa_guard_acquire (&_ZGVZ3foovE1a); >> ... >> >> So, right now tsan would just instrument it as __tsan_read1 from >> &_ZGVZ3foovE1a rather than any atomic load. > > > Looks like a bug. That needs to be load-acquire with proper compiler > and hardware memory ordering.
