https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #26 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #25)
> (In reply to Hans-Peter Nilsson from comment #23)
> > ...and also, a call might be generated as the result of using
> > __atomic_is_lock_free (instead of __atomic_always_lock_free), so the target
> > may change its mind. Not good.
>
> That should have been fixed by r227878 for Bug 65913 so that for these cases
> no call is generated.
I went by the documentation, which says at r264855 for __atomic_is_lock_free
that "If the built-in function is not known to be lock-free, a call is made to
a runtime routine named @code{__atomic_is_lock_free}." It certainly seems to
be that way too (builtins.c):
static tree
fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
{
if (!flag_inline_atomics)
return NULL_TREE;
/* If it isn't always lock free, don't generate a result. */
if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
return boolean_true_node;
return NULL_TREE;
}
ISTM that this will not "inline" a return of "false".
