[Bug libgomp/40362] openmp: some libgomp functions trigger data races

["dvyukov at google dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.