Does volatile act as a compiler barrier for optimization

Question

Is the compiler allowed to optimize the code flow by moving statements (not parts of an expression) from before a volatile access to afterwards, or from after a volatile access to before it.

In reference to my answer to SO : is volatile required for synchronous ISR access

Objections to my answer has suggested that the use of volatile does not cause the generalized machine for C++ (and C) to ensure that all operations before hand are completed.

My reading of cppreference : const volatile

that is, within a single thread of execution, volatile accesses cannot be optimized out or reordered with another visible side effect that is sequenced-before or sequenced-after the volatile access. This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution

Is that for the case in my answer - single core operation the following should be true.

• The results are visible as fast as possible - there may be a point where a change to a volatile hasn't been written, but if it is written, then the single core would see it in a signal handler, (or an ISR).
• A compliant C++ compiler would not be able to re-order operations around the volatile write as it is a visible side effect.

My answer on this thread assumed the particular case was a single core CPU, and that C++11 was not applicable, so I would prefer answers within that scope.

Answer 1

The C++ standard does not distinguish between what the code flow says and what the code does. So this, and all questions about code flow rather than observable behavior, is a platform-specific question.

A compliant C++ compiler would not be able to re-order operations around the volatile write as it is a visible side effect.

Nobody understands the standard to say that. This is why x86 compilers do not put memory barriers around volatile operations and do permit re-ordering by the CPU.