Re: [PATCH 1/2] x86,s390: add compiler memory barriers when expanding atomic_thread_fence (PR 80640)

[Alexander Monakov <amonakov at ispras dot ru>]

On Thu, 8 Jun 2017, Alexander Monakov wrote:
> Ping^3.

Ping^4: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00782.html

This is a wrong-code issue with C11 atomics: even if no machine barrier is
needed for a given fence type on this architecture, a compiler barrier must
be present in RTL.

Alternatively, it's possible to have a more complete and future-proof solution
by explicitly emitting a compiler barrier from the middle-end, leaving it up
to the backend to emit a machine barrier if needed.  The following patch could
achieve that (but at the cost of creating slightly redundant RTL on targets
that always emit some kind of memory barrier).

	* optabs.c (expand_mem_thread_fence): Always emit a compiler barrier
	if using mem_thread_fence expansion.

diff --git a/gcc/optabs.c b/gcc/optabs.c
index 8fd5d91..92080c3 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -6297,7 +6297,11 @@ void
 expand_mem_thread_fence (enum memmodel model)
 {
   if (targetm.have_mem_thread_fence ())
-    emit_insn (targetm.gen_mem_thread_fence (GEN_INT (model)));
+    {
+      emit_insn (targetm.gen_mem_thread_fence (GEN_INT (model)));
+      if (!is_mm_relaxed (model))
+       expand_asm_memory_barrier ();
+    }
   else if (!is_mm_relaxed (model))
     {
       if (targetm.have_memory_barrier ())