Re: should sync builtins be full optimization barriers?

[Paolo Bonzini <bonzini at gnu dot org>]

On Sat, Sep 10, 2011 at 03:09, Geert Bosch <bosch@adacore.com> wrote:
> For example, for atomic objects accessed only from a single processor
> (but ?possibly multiple threads), you'd not want the compiler to reorder
> memory accesses to global variables across the atomic operations, but
> you wouldn't have ?to emit the expensive fences.

I am not 100% sure, but I tend to disagree.  The original bug report
can be represented as

   node->next = NULL [relaxed];
   xchg(tail, node) [seq_cst];

and the problem was that the two operations were swapped.  But that's
not a problem with the first access, but rather with the second.  So
it should be fine if the  [relaxed] access does not include a barrier,
because it relies on the [seq_cst] access providing it later.

Paolo