[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

[Dimitry Andric via Phabricator via cfe-commits]

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