[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property

["bin.x.fan at oracle dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from Bin Fan <bin.x.fan at oracle dot com> ---
(In reply to Jason Merrill from comment #3)
> (In reply to Bin Fan from comment #0)
> > 2. g++ tries to make lock-free property per-type, but the libatomic.so
> > implementation does not match.
> 
> This.  We always pass a null pointer to libatomic and do not pass any
> information about the alignment of the type.  rth suggested that we might
> try passing a fake, minimally-aligned pointer instead of null as a way of
> communicating the alignment without adding a new entry point.

So after the fix, atomic_is_lock_free will always return 0 for size=3,align=1
atomic struct objects?

I understand currently libatomic tries to make an atomic object lock-free if
its memory location fit in a certain sized window. So for atomic operations
such as atomic_store where the actual address is passed in, the operation can
be still either lock-free or locked, right? I'm wondering if it's standard
conforming since the lock-free property is still per-object, or it can be seen
as an optimization, i.e. atomic_is_lock_free query for the object returns 0,
but atomic operations on the object could be lock-free.