On Tue, Nov 23, 2010 at 12:34 AM, Richard Sandiford richard.sandiford@linaro.org wrote:

For the record, the thing I half-remembered on the call was:

http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00697.html and:    http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02112.html

The problem is that all __sync operations besides __sync_lock_test_and_set and __sync_lock_release are defined to be full barriers.  Using something like __sync_val_compare_and_swap for __arch_compare_and_exchange_val_*_acq and __arch_compare_and_exchange_val_*_rel may on some architectures be too heavyweight, since those macros only need acquire/after and release/before barriers.  See in particular:

http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00928.html

from the first thread, where the feeling was that the future wasn't these __sync builtins, but the new C and C++ atomic memory support.

Probably already known, sorry.  I just wasn't sure that trying to convert everyone (not just ARM) to __sync_* was necessarily going to go down well.

Good point. Using __sync in ARM only is fine, but please do bring the topic up with upstream.

I'd forgotten about LLVM when we were talking yesterday. Both GCC and LLVM supply sync primitives and I hope RVDS will soon as well.

-- Michael