dim added a comment. In https://reviews.llvm.org/D28213#666196, @mgorny wrote:
> In https://reviews.llvm.org/D28213#665967, @dim wrote: > > > I don't think FreeBSD has lock-free 64 bit atomic operations on 32-bit x86. > > IIRC we already had some trouble before with clang emitting libcalls to > > `__atomic_fetch_add_8` and friends, which then lead to linking errors. > > > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216745, where this is > > now occurring with boost. > > > Could you try to figure out what's the cause for that discrepancy? I think the discrepancy is that many 32-bit Linuxes target at least i686 by default, and then you have CMPXCHG8B most of the time (apparently not always, but nobody seems to care): $ uname -srm Linux 3.16.0-4-686-pae i686 $ gcc -dM -E -x c /dev/null | grep LLONG_LOCK #define __GCC_ATOMIC_LLONG_LOCK_FREE 2 However, 32-bit FreeBSD targets i486 by default: $ uname -srm FreeBSD 12.0-CURRENT i386 $ gcc -dM -E -x c /dev/null | grep LLONG_LOCK #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 $ clang-3.9.1 -dM -E -x c /dev/null | grep LLONG_LOCK #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 $ clang-4.0.0 -dM -E -x c /dev/null | grep LLONG_LOCK #define __GCC_ATOMIC_LLONG_LOCK_FREE 2 Note that even on 32-bit Linux you get 1 for `__GCC_ATOMIC_LLONG_LOCK_FREE`, if you target i486: $ uname -srm Linux 3.16.0-4-686-pae i686 $ gcc -march=i486 -dM -E -x c /dev/null | grep LLONG_LOCK #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 > What's the value of `__atomic_always_lock_free(sizeof(long long), 0)` for gcc > and clang? For gcc, it is always 0, for clang (I tested 3.4.1 through 4.0.0) it is always 1. Maybe that was always incorrect on 32-bit FreeBSD, then? Repository: rL LLVM https://reviews.llvm.org/D28213 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
