long long not lockfree on i686 compiled with clang

[gjasny@…]

$ clang --version Hello,

I just discovered that the lockfree test fails on trunk:

BEGIN OUTPUT

atomic<char> is always lock free atomic<short> is always lock free atomic<int> is always lock free atomic<long> is always lock free lockfree.cpp(29): test lock_free_macro_val == lock_free_expect failed in function: 'void verify_lock_free(const char *, int, int) [T = long long]' atomic<long long> is never lock free atomic<void *> is always lock free atomic<bool> is always lock free

My system is a Mac with 10.9 and Xcode 5.1: Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix

I build the three with: b2 toolset=darwin architecture=x86 address-model=32

I think t boils down to the following:

$ clang -march=core2 -dM -E - -m32 < /dev/null|grep -i GCC_ATOMIC_LLONG_LOCK_FREE #define GCC_ATOMIC_LLONG_LOCK_FREE 1

The lockfree test expects 2 here.

(Clang 3.4 on Linux also just returns 1 for long long).

If I change the code in the platform header and switch from gcc-atomic.hpp to gcc-x86.hpp the test passes.

Thanks, Gregor

[gregor.jasny@…]

Sorry for the messy formatting. It was late and I hit the wrong button.

I just reproduced this on Redhat EL 6 with Clang from EPEL.

[Andrey Semashev]

I believe there is a bug in clang because all Core 2 generation CPUs support cmpxchg8b instruction or 64-bit cmpxchg in 64-bit mode. The compiler should be defining the __GCC_ATOMIC_LLONG_LOCK_FREE macro to 2. This is what gcc does. Please, report it to clang team.

As for Boost.Atomic behavior, it currently does not support "possibly hardware-supported" atomics because in some cases this results in linking errors.

In this ticket we could probably work around the clang bug, if it also defines the target CPU macros correctly. If it doesn't there's really nothing we can do. Please, attach a full output of the clang -march=core2 -dM -E - -m32 < /dev/null command to this ticket.

[gjasny@…]

I filed a bug report as LLVM Bug report #19355

[gjasny@…]

clang preprocessor symbols - Xcode 5.1 (5B130a)

[anonymous]

Replying to andysem:

[gjasny@…]

Hello,

since creation the Clang bug did not receive any attention. And because we cannot change the past I'd suggest that we try to work-around for now.

Thanks, Gregor

[Andrey Semashev]

I've already added a workaround (although not tested) to my decouple_interface_impl_rewrite branch. I hope I'll be able to finish it and merge to develop before the release.

[Andrey Semashev]

The new version has been merged to develop and master and will be released in 1.56.