http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
--- Comment #14 from Dmitry Vyukov <dvyukov at google dot com> 2012-12-29 22:36:11 UTC --- (In reply to comment #13) > (In reply to comment #12) > > ws = gomp_ptrlock_get (&ws->next_ws); > > This is really just: > ws = gomp_ptrlock_get (ws+offsetof(next_ws)); > > So there are no loads there. The race is between store to ws->end/incr/chunk_size in gomp_loop_init() and loads in gomp_iter_dynamic_next(). They are not synchronized in any way. So a worker thread can load bogus ws->end/incr/chunk_size. There is another race on thr->ts.last_work_share->next_ws.ptr in ptrlock_get()/set(). > This is a race condition only if we go from > non-null to null which cannot happen here. This *is* the race condition. Period. There is no if. Undefined behavior. > TSAN cannot detect that as it does > not understand that case which is a complex case to understand This is trivial case and tsan correctly identifies it as a data race. > Also does TSAN understand futex's which might the other thing throwing it off > just as Hellgrtind and drd was thrown off by it. This data race is not related to futexes. Moreover, futexes rarely provide synchronization, just as condition variables they are usually used as wait optimization. For example futexes in config/linux/mutex.c do not provide any synchronization, so there is nothing to undertand.
