Eagerly evaluate __atomic_is_lock_free to 0 for oversized types
Jonathan Wakely
jwakely.gcc@gmail.com
Tue Feb 11 14:11:00 GMT 2020
On Tue, 11 Feb 2020 at 04:34, Fangrui Song <i@maskray.me> wrote:
>
> GCC never evaluates __atomic_is_lock_free to 0. (gcc/builtins.c:fold_builtin_atomic_always_lock_free)
> I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for apparently oversized types.
> This helps some platforms to avoid a dependency on libatomic.
>
> Either of the following choices can move my patch https://reviews.llvm.org/D72579 forward:
>
> * GCC will like do the same
> * GCC is committed to not extend __atomic_is_lock_free in a clang incompatible way.
We discussed this on IRC in #gcc. There was no motivation to change
GCC. The platform that wants to avoid the libatomic dependency doesn't
use GCC anyway. Relying on not getting the libatomic dependency seems
fragile (it only works for a specific codebase, and if some other
is_lock_free check is added to the codebase, the libatomic dependency
will return anyway).
More information about the Gcc
mailing list