[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Comment on attachment 44851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44851
patch as per directions

That looks like sufficient variety of types tested.

I would prefer a function template instead of the LF macro e.g.

template<typename T>
void check()
{
  std::atomic<T> a;
  VERIFY( a.is_lock_free() || !a.is_always_lock_free );
}

and then:

  check< Foo * >();
  check< Bar * >();

etc.

But I'm losing confidence in this change being correct, after asking some
questions of the C++ committee. The intent seems to be that is_lock_free() can
indeed give a runtime answer, based on properties which might not have been
known at compile-time. For example, code compiled with -march=i386 will say
is_always_lock_free is false (correctly) but if at runtime it links to
libatomic compiled for i686 and it runs on i686 then is_lock_free could return
true. So the link failure in comment 30 is right, and I was wrong to say:

> The result should be the same as ax.is_always_lock_free which is a constant.

This is the point Andrew made all the way back in Comment 2. At compile-time we
might not be able to guarantee lock-freedom, but at run-time libatomic might be
able to **and that will be true for all suitably-aligned objects of that
type**.

So the premise that "is_lock_free() is per-type implies it's the same as
always_lock_free" is wrong.