On Mon, Feb 10, 2020 at 8:35 PM Fangrui Song <i...@maskray.me> wrote:
>
> GCC never evaluates __atomic_is_lock_free to 0.
> (gcc/builtins.c:fold_builtin_atomic_always_lock_free)
Huh?
/* We need a corresponding integer mode for the access to be lock-free. */
size = INTVAL (expand_normal (arg0)) * BITS_PER_UNIT;
if (!int_mode_for_size (size, 0).exists (&mode))
return boolean_false_node;
...
/* If the object has smaller alignment, the lock free routines cannot
be used. */
if (type_align < mode_align)
return boolean_false_node;
/* Check if a compare_and_swap pattern exists for the mode which represents
the required size. The pattern is not allowed to fail, so the existence
of the pattern indicates support is present. Also require that an
atomic load exists for the required size. */
if (can_compare_and_swap_p (mode, true) && can_atomic_load_p (mode))
return boolean_true_node;
else
return boolean_false_node;
Thanks,
Andrew Pinski
> 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.
