On Tue, Nov 23, 2010 at 12:34 AM, Richard Sandiford <richard.sandif...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
