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

["pinskia at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-29 12:09:15 UTC ---
(In reply to comment #10)
> gomp_ptrlock_get() function is not thread-safe. It's not only about atomicity,
> it's also about memory ordering. Thread that calls gomp_ptrlock_set() can
> reorder stores to ws and the store to ptrlock->ptr. Alpha processors can even
> reorder load from ws and load of ptrlock->ptr (they do not respect data
> dependencies).

Wait a second ptrlock->ptr is really ws->next_ws.ptr which is really
(ws+offset) so there is no data dependency here as far as I can see.  As Jakub
mentioned before ws->next_ws.ptr only from NULL to non-null.  So as far as I
can tell it still stands as being thread-safe just not detectable from either
valgrind or tsan.  This is just like some of the false uninitialized warnings
which gcc can emit.  It is sometimes hard to prove that the code is fine except
with extra knowledge like the NULL to non-NULL.

And about the stores being reordered:
    gomp_ptrlock_set (&thr->ts.last_work_share->next_ws, thr->ts.work_share);

so ptr is always ws.

I again looked at the code and I still agree with Jakub's reasoning.