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

[hp at gcc dot gnu.org]

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

--- Comment #27 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #24)
> (In reply to Hans-Peter Nilsson from comment #22)
> > Or do I misread that?  Are __alignof(x) and the result of alignas(x)
> > in the declaration guaranteed to always be the same here?
> 
> Yes.

For the combination of alignof and alignas in *this* code it's not
obvious to me.  I can imagine that (for example) the alignment of a
container can affect the __alignof(x) such that it's (for example)
higher than the specifically alignas declaration of x, likely by bug,
less likely by intent.  IOW, to me, this isn't the alignas(type) ===
alignas(alignof(type)) in
<https://en.cppreference.com/w/cpp/language/alignas>.

Either way, whether the guarantee is by C++ standard wording or by gcc
internals documentation carries not more value than the documentation
for __atomic_is_lock_free when it comes to maintainer reading, heh...

So, what I'd like to see is either:

- This change in atomic_base.h, avoiding use of the specific object in
is_lock_free and changing to __atomic_always_lock_free:

Index: atomic_base.h
===================================================================
--- atomic_base.h       (revision 264855)
+++ atomic_base.h       (working copy)
@@ -355,7 +355,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
       {
        // Use a fake, minimally aligned pointer.
        return __atomic_is_lock_free(sizeof(_M_i),
-           reinterpret_cast<void *>(-__alignof(_M_i)));
+           reinterpret_cast<void *>(-_S_alignment));
       }

       bool
@@ -363,7 +363,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
       {
        // Use a fake, minimally aligned pointer.
        return __atomic_always_lock_free(sizeof(_M_i),
-           reinterpret_cast<void *>(-__alignof(_M_i)));
+           reinterpret_cast<void *>(-_S_alignment));
       }

       _GLIBCXX_ALWAYS_INLINE void

(Note the change to __atomic_always_lock_free.  BTW, why use __alignof and not
alignof?  No underscores in the _S_alignment expression!)

-or-

- at least a test in the C++ test-suite with at least a construct of
the exact same form as the one in atomic_base.h but with an overaligned
container and an assert that the alignof the inner object equals the
alignas expression, as you asserted above.  I know that'd cover only
the first case of alignment-bleed that comes to mind, but it'd
indicate an intent to future hackers.

- optionally: wording in the gcc documentation to the effect of the
__alignof === alignas guarantee.  (Still, a test-case is more reliable
than gcc documentation.)  But, there's probably sufficient wording in the
standard.

Maybe some of that is already in place; if it isn't, I'll produce
patches (and CC you, hoping for speedier review).

Do we have common ground here?