<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 11, 2022, 2:32 AM Rémi Bernon <<a href="mailto:rbernon@codeweavers.com">rbernon@codeweavers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2/10/22 18:18, Jinoh Kang wrote:<br>
> GCC, clang, and other compilers do not actually provide acquire/release<br>
> semantics on volatile memory accesses.  This is also true on MSVC with<br>
> the /volatile:iso (use strict ISO C semantics for volatile accesses)<br>
> flag.<br>
> <br>
> Consider the following test program:<br>
> <br>
>      void func(int *foo, volatile int *bar)<br>
>      {<br>
>          *foo = 1;<br>
>          *bar = 2;  /* NOTE: *not* immune to reordering! */<br>
>          *foo = 3;<br>
>      }<br>
> <br>
> After store reordering and dead code removal, the function above<br>
> compiles into the following x86-64 assembly on GCC 11.2 (gcc -O2):<br>
> <br>
>      movl $2, (%rsi)<br>
>      movl $3, (%rdi)<br>
>      ret<br>
> <br>
> Note that the first write to "*foo" has been ellided; the compiler<br>
> decided that it is safe to reorder writes to "*foo" around writes to the<br>
> volatile variable "*bar", so it simply merged the first "*foo" write<br>
> into the second one.<br>
> <br>
> Fix this by explicitly specifying a compiler memory barrier before the<br>
> atomic store.  As a workaround for GCC bug #81316, we do this even for<br>
> other architectures where we explicitly use the atomic memory access<br>
> builtin.<br>
> <br>
FWIW I believe that the only thing that matters for these helpers and <br>
where they are used (to write to user shared data section) is that the <br>
ordering is guaranteed between the volatile stores, not really with <br>
other load or stores on non-volatile data around them. This should be <br>
the case.<br>
<br>
Then maybe they shouldn't be named atomic, because they aren't. Or, if <br>
we really want to fix the semantics here, maybe we should just use the <br>
__atomic intrinsics everywhere. The concern was the compatibility with <br>
older GCC or non-GCC compilers, and I don't think they are much less <br>
portable than inline assembly at this point.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">We still support GCC 4.x (an in-support RHEL/CentOS release uses it), so I think we still need some wrappers around it. That and the GCC bug.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Rémi Bernon <<a href="mailto:rbernon@codeweavers.com" target="_blank" rel="noreferrer">rbernon@codeweavers.com</a>><br>
<br>
</blockquote></div></div></div>