Boost C++ Libraries: Ticket #9842: long long not lockfree on i686 compiled with clang

gregor.jasny@… — Mon, 07 Apr 2014 06:31:27 GMT

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.

cc set

Andrey Semashev — Mon, 07 Apr 2014 07:47:44 GMT

cc Andrey.Semashev@… added

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@… — Mon, 07 Apr 2014 16:52:31 GMT

I filed a bug report as LLVM Bug report #19355

attachment set

gjasny@… — Mon, 07 Apr 2014 16:53:44 GMT

attachment → clang-preprocessor.txt

clang preprocessor symbols - Xcode 5.1 (5B130a)

anonymous — Thu, 17 Apr 2014 05:25:57 GMT

Replying to andysem:

gjasny@… — Wed, 23 Apr 2014 11:14:40 GMT

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 — Wed, 23 Apr 2014 11:35:01 GMT

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.

status changed; resolution set

Andrey Semashev — Sat, 17 May 2014 16:15:37 GMT

status new → closed
resolution → fixed

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