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 ())
