Bug#727621: armv5 and ATOMIC_INT_LOCK_FREE
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#_005f_005fatomic-Builtins
>
> Yvan
Reply to: