[Bug target/80640] Missing memory side effect with __atomic_thread_fence (2)

torvald at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Oct 20 10:46:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640

torvald at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |torvald at gcc dot gnu.org

--- Comment #11 from torvald at gcc dot gnu.org ---
(In reply to Alexander Monakov from comment #7)
> I've submitted a patch [1] for the missing compiler barrier, but however
> please note that the original ompi code and the example in comment #3 are
> wrong: in a pattern like
> 
>   while (*foo)
>     __atomic_thread_fence(__ATOMIC_ACQUIRE);
> 
> I think there are two issues; first, if *foo is a non-atomic, non-volatile
> object, a concurrent modification from another thread would invoke undefined
> behavior due to a data race;

It would be a data race even if it would be volatile but still non-atomic.

I can see how making atomic_thread_fence a compiler barrier for non-atomics
might help existing buggy code, but it would be sufficient it prevents certain
reordering of atomics.

Some more background and examples:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html


More information about the Gcc-bugs mailing list