https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #18 from Ruslan Nikolaev <nruslan_devel at yahoo dot com> --- (In reply to andysem from comment #17) > I'll clarify why I think load() should be allowed to issue writes on the > memory. According to [atomics.types.operations]/18 in N4713, > compare_exchange_*() is a load operation if the comparison fails, yet we > know cmpxchg (even the ones more narrow than cmpxchg16b) always writes, so > we must assume a load operation may write. I do not find a definition of a > "load operation" in the standard and [atomics.types.operations]/12 and 13 > avoid this term, saying that load() "Atomically returns the value pointed to > by this." Again, it doesn't say anything about writes to the memory. > > So, if compare_exchange_*() is allowed to write on failure, why load() > shouldn't be? Either compare_exchange_*() issuing writes is a bug (in which > case a lock-free CAS can't be implemented on x86 at all) or writes in load() > should be allowed and the change wrt. cmpxchg16b should be reverted. I think, there is way too much over-thinking about read-only case for 128-bit atomics. Current solution is very confusing and not very well documented at the very least. Correct me if I am wrong, but does current solution guarantee address-freedom? If not, what is the motivation to support 128-bit read only atomics? The only practical use case seems to be IPC where one process has a read-only access. If not guaranteed for 128-bit, why even bother to support read-only case which is a) not guaranteed to be lock-free b) works only within a single process where it is easy to control read-only behavior. I really prefer the way it was implemented in clang. It is only redirecting if -mcx16 is not specified. BTW, it also provides very nice implementation for Aarch64 which GCC is also lacking.
