Alexander, Thank you for your comments. Please see my response below. I definitely do not want to fight for or against this change in gcc, but there are definitely legitimate concerns to consider. I think, it would really be good to consider this change to make things more compatible (i.e., at least between clang/llvm and gcc which can be both used within the same ecosystem). There are real practical benefits of having true lock-free double-width operations when implementing algorithms that rely on ABA tagging for pointers, and C11 at last gives an opportunity to do that without resorting to assembly or platform-specific implementations.
> Note that there's more issues to that than just behavior on readonly memory: > you need to ensure that the whole program, including all static and shared > libraries, is compiled with -mcx16 (and currently there's no ld.so/ld-level > support to ensure that), or you'd need to be sure that it's safe to mix code > compiled with different -mcx16 settings because it never happens to interop > on wide atomic objects. Well, if libatomic is already doing it when corresponding CPU feature is available (i.e., effectively implementing operations using cmpxchg16b), I do not see any problem here. mcx16 implies that you *have* cmpxchg16b, therefore other code compiled without -mcx16 flag will go to libatomic. Inside libatomic, it will detect that cmpxchg16b *is* available, thus making code compiled with and without -mcx16 flag completely compatible on a given system. Or do I miss something here? If you do not have cmpxchg16b, but the program is compiled with the flag, it will simply not run (as expected). So, in other words, libatomic should still decide whether you have cmpxchg16b or not for cases when -mcx16 is not specified. But if it is specified, cmpxchg16b can be generated unconditionally. If you want better compatibility, you will not specify the flag. Mix of -mcx16 and mno-cx16 will be, thus, binary compatible. > Note that there's no "load" function in the __sync family, so the original > concern about operations on readonly memory does not apply. Yes, but per clarification from WG14/C11, read-only memory should not be a concern at all, as this behavior is not specified anyway (regardless of the const specifier). Read-modify-write is allowed for atomic_load as long as there is no 'visible' change on the value being loaded. In this sense, the bug that was filed previously regarding read-only memory accesses and const specifier does not seem to be valid. Additionally, it is really odd and counterintuitive to still provide support for (almost) deprecated macros while not giving such an opportunity for newer and more advanced functions. > You don't mention it directly, so just to make it clear for readers: on > systems > where GNU IFUNC extension is available (i.e. on Glibc), libatomic tries to do > exactly that: test for cmpxchg16b availability and redirect 128-bit atomics to > lock-free RMW implementations if so. (I don't like this solution) Yes, but libatomic makes things slower due to indirection. Also, it is much harder to track what is going on, as there is no guarantee of lock-freedom in this case. BTW -- The fact that it currently uses cmpxchg16b if available may actually be helpful to switch to the suggested behavior without breaking binary compatibility (if I understand everything correctly). -- Ruslan
