https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
--- Comment #10 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- (In reply to Wilco from comment #9) > (In reply to Xi Ruoyao from comment #8) > > (In reply to Wilco from comment #7) > > > I don't see the issue you have here. GCC for x86/x86_64 has been using > > > compare exchange for atomic load (which always does a write even if the > > > compare fails) for many years. > > > > No we don't, since r7-6454. > > Incorrect - libatomic still uses cmpxchg16b depending on the CPU. You are incorrect. It checks cmpxchg16b bit in CPUID but does not use the cmpxchg16b instruction. The reason to check cmpxchg16b is both Intel and AMD guarantee that if both cmpxchg16b and AVX are available, then an aligned 16-byte load with vmovdqa is atomic. So we can use vmovdqa to do a lock-free load then. But using cmpxchg16b for a load is still wrong, and libatomic do NOT use it. > > > The question is, do you believe compilers should provide users with fast > > > and > > > efficient atomics they need? Or do you want to force every application to > > > implement their own version of 128-bit atomics? > > > > But a compiler must generate correct code first. They can use the wonderful > > inline assembly because they know CAS is safe in their case, but the > > compiler does not know. > > Many developers consider locking atomics fundamentally incorrect. If we emit > lock-free atomics they don't need to write inline assembler. Then the compiler (and the standard) is not what they consider. Such misunderstandings are everywhere and this has no difference.
