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

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19355

            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

Hello,

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
1.
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
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2

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
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1

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
free.

Thanks,
Gregor

[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>