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.
