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.r...@linaro.org> wrote: > On 3 December 2013 01:19, Nicolas Pitre <nicolas.pi...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
