According to this bugzilla entry, the issue is how ATOMIC_INT_LOCK_FREE is computed, which is not the same as the for the __atomic_always_lock_free builtin (I checked on armv5 the builtin is true for int whereas the macro value is 1). There is a proposed patch, but it still has some issues... have to think more to that.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006

Yvan

On 3 December 2013 13:33, Yvan Roux yvan.roux@linaro.org wrote:

On 3 December 2013 01:19, Nicolas Pitre nicolas.pitre@linaro.org wrote:

...

On Mon, 2 Dec 2013, Riku Voipio wrote:

...

Hi,

According the debian bug report [1], it is not possible to use std::future on armv5 targetting toolchains. This is because libstdc++ will only enable std::future if ATOMIC_INT_LOCK_FREE > 1. There is no LDREX for armv5 and older, so this definition is set to ATOMIC_INT_LOCK_FREE when compiling for ARMv4t or ARMv5.

My impression is that you should be able to use the kernel helpers for atomic operations in lockfree (?) manner, so the ATOMIC_INT_LOCK_FREE definition is probably incorrect on older arm archs then?

You're absolutely right.

Please see Documentation/arm/kernel_user_helpers.txt in the kernel source tree for details. There is even an example implementation for atomic_add() there.

Also I remember gcc being added some native atomic operation support at some point and they were implemented in terms of the kernel helpers when the architecture level wasn't high enough to benefit from load/store exclusive instructions.

Nicolas

Nicolas is right, GCC has now a set of bult-in functions which try to match the Cxx11 memory model. The description is in the manual here:

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/_005f_005fatomic-Builtins.html#_...

Yvan