| Message ID | alpine.LNX.2.20.13.1707112127420.2537@monopod.intra.ispras.ru |
|---|---|
| State | New |
| Headers | show |
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 ())
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.