https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #8 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Niall Douglas from comment #7) > (In reply to Andrew Pinski from comment #4) > > (In reply to Niall Douglas from comment #3) > > > You may be interested in reading https://reviews.llvm.org/D110069. It > > > wanted > > > to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that > > > change, it'll be in the next release. > > > > Using CAS for atomic load is not valid thing to do ... > > Because atomic load from constant rodata needs to work. > > LLVM breaks this case as they don't care about it. GCC does though. > > I've heard that argument before, and I've always wondered why _Atomic128 > types couldn't have an attribute which applies attribute section to their > static const variable incarnations to force them into r/w memory. That would > also solve the LLVM issue. Said attribute is not unuseful in general > actually, it would help avoid having to mess with mprotect to apply copy on > write perms on regions in .rodata when you need to modify static const > variable values. > > I don't think that the standard *guarantees* that static const variables go > into read only memory, and besides, before C23 128 bit integers weren't > supported anyway so one could argue as a proprietary extension (__int128) > you get proprietary special casing. Yes that sounds like a reasonable approach. There will language lawyers that say it must also work on mmap after mprotect of course, but that seems even more unlikely in the real world... I believe that the vast majority of developers just want 128-bit atomics to work efficiently without locks when possible. Currently various packages are forced to create 128-bit atomics using inline assembler - and that seems a much worse hack than supporting lock-free atomics in the compiler.
