[Bug target/67458] x86: atomic store with memory_order_release doesn't order other stores

[peter at cordes dot ca]

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

--- Comment #5 from Peter Cordes <peter at cordes dot ca> ---
> optabs: ensure atomic_load/stores have compiler barriers

Thanks for taking a look at this report.  But I think it's not necessary to
have a full 2-way barrier.  If there's a lighter-weight way to get the
behaviour we want, that would be better.

(In reply to Peter Cordes from comment #0)
> void set(void) {
>   b = 2;
>   a.store(1, memory_order_release);
>   b = 3;
> }

Looking at this again with a couple years more understanding of atomics,
probably gcc could optimize to 

  b = 3;
  a.store();

because a release-store is only a *1-way barrier*.  (Unlike
atomic_signal_fence() or atomic_thread_fence(). 
http://preshing.com/20131125/acquire-and-release-fences-dont-work-the-way-youd-expect/).


I think even the original behaviour (a.store(); b=3;)  might actually have been
technically legal C++11, because you couldn't observe the reordering without
invoking UB.

A thread that does an a.load(mo_acquire) will still cause C++11 UB if it reads
b, because b isn't atomic but there's a data race because it was written after
the release operation that we synchronize-with.

Thus, no other thread is allowed to look at  b  any time after this thread ran
set(), until another synchronizes-with.