This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Eagerly evaluate __atomic_is_lock_free to 0 for oversized types
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Fangrui Song <i at maskray dot me>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 11 Feb 2020 14:11:03 +0000
- Subject: Re: Eagerly evaluate __atomic_is_lock_free to 0 for oversized types
- References: <20200211043438.jcez7nnruetnpk4p@gmail.com>
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).