https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
--- Comment #11 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Xi Ruoyao from comment #10) > (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. No, it will use the cmpxchg16b instruction in the other ifunc when AVX is not available. Libatomic will fallback to locking atomics if neither AVX nor cmpxchg16b are available (first few generations of x86_64). > 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. Where is int128 in "the standard"?
