Thank you for more comments, my response is below.
On Mon, 26 Feb 2018, Szabolcs Nagy wrote:> > rmw load is only valid if the implementation can > guarantee that atomic objects are never read-only. But per response from WG14 regarding DR 459 which I quoted, the standard does not seem to define behavior for read-only memory (and const qualifier should not suggest that). RMW, according to them, is fine for atomic_load. > current implementations on linux (including clang) > don't do that, so an rmw load can observably break > conforming c code: a static global const object is > placed in .rodata section and thus rmw on it is a > crash at runtime contrary to c standard requirements. I have just tried to compile the code using clang. Latest stable version of clang seems to emit cmpxchg16b for the code you mentioned if I specify mcx16. If I do not, it redirects to libatomic. (I have not tried the version from the trunk, though.) On Monday, February 26, 2018 8:57 AM, Alexander Monakov wrote: > OK, but that sounds like a matter of not emitting atomic > objects into .rodata, which shouldn't be a big problem, > if not for backwards compatibility concern? I agree, sounds like a good idea. Certainly for _Atomic objects > 8 bytes. > and then with new enough libatomic on Glibc this segfaults > with GCC on x86_64 too due to IFUNC redirection mentioned > in the other subthread. Seems like it is a problem anyway. Another reason to never emit _Atomic inside .rodata
