https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #27 from Peter Cordes <peter at cordes dot ca> --- (In reply to Alexander Monakov from comment #26) > Sure, the right course of action seems to be to simply document that atomic > types and built-ins are meant to be used on "common" (writeback) memory Agreed. Where in the manual should this go? Maybe a new subsection of the chapter about __atomic builtins where we document per-ISA requirements for them to actually work? e.g. x86 memory-type stuff, and that ARM assumes all cores are in the same inner-shareable cache-coherency domain, thus barriers are dmb ish not dmb sy and so on. I guess we might want to avoid documenting the actual asm implementation strategies in the main manual, because that would imply it's supported to make assumptions based on that. Putting it near the __atomic docs might make it easier for readers to notice that the list of requirements exists, vs. scattering them into different pages for different ISAs. And we don't currently have any section in the manual about per-ISA quirks or requirements, just about command-line options, builtins, and attributes that are per-ISA, so there's no existing page where this could get tacked on. This would also be a place where we can document that __atomic ops are address-free when they're lock-free, and thus usable on shared memory between processes. ISO C++ says that *should* be the case for std::atomic<T>, but doesn't standardize the existence of multiple processes. To avoid undue worry, documentation about this should probably start by saying that normal programs (running under mainstream OSes) don't have to worry about it or do anything special.
