[LLVMbugs] [Bug 19355] New: __GCC_ATOMIC_LLONG_LOCK_FREE only set to 1 on X86

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Apr 7 09:43:19 PDT 2014


            Bug ID: 19355
           Summary: __GCC_ATOMIC_LLONG_LOCK_FREE only set to 1 on X86
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gjasny at googlemail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


when compiling the Boost Atomic library I noticed a test case failure which
expects that boost::atomic<long long> is always lock-free on X86 [1].

This is caused by the fact that clang sets the __GCC_ATOMIC_LLONG_LOCK_FREE to
In comparison gcc (4.8) sets this preprocessor symbol to 2:

$ gcc --version
gcc (Debian 4.8.2-19) 4.8.2
$ gcc -dM -E - -m32 < /dev/null|grep __GCC_ATOMIC_LLONG_LOCK_FREE

In contrast:

$ clang --version
Debian clang version 3.4-2 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ clang -dM -E - -m32 < /dev/null|grep __GCC_ATOMIC_LLONG_LOCK_FREE

Is this difference a bug? Andrey Semashev stated in the Boost Atomic bug report
that Core2 CPUs all should support cmpxchg8b and thus be always completely lock


[1] See https://svn.boost.org/trac/boost/ticket/9842

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140407/69e7e452/attachment.html>

More information about the llvm-bugs mailing list