With one exception, the relevant details aren't really compiler-specific, and C++20 keeps the relevant parts... if you perform two operations on volatile values

With one exception, the relevant details aren't really compiler-specific, and C++20 keeps the relevant parts... if you perform two operations on volatile values, the operations can't be reordered, because the spec says so. > Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine. Not the best, clearest, most useful part of the C++ spec but the core concept is there... if you perform operation A on a volatile object, then perform operation B on a volatile object, the emitted code must perform A before B. To my knowledge, this part of the C++ standard hasn't even changed wording in C++20, and isn't deprecated either. The compiler-specific parts are things like: 1. Is this a compiler fence? (If no, the buffer in a ring buffer must also be volatile.) 2. Is this a memory fence? 3. Is there some platform-specific way in which operations on volatile objects are different? The part you do need to know is if the operation will tear.