The implementation-definedness is a little bit irrelevant since there is pretty solid agreement among compiler developers and compiler users that a volatile on the RHS of an expression means the volatile location should be loaded from, and a volatile on the LHS of an expression means the volatile location should be stored to.

Basically, in spite of some ugly stuff in the standard, people want and need a usable language for systems work.

__asm__ __volatile__ ("dmb" : : : "memory");

is also implementation-defined, so the suggested solution (and the suggested class of solutions) is not really a solution to anything at all.

Thanks for the information.

I suspect we largely agree. It probably sounds like I’m trying to defend the standard and the implementations but my intent is just to come up with a pragmatic explanation of the situation that developers are likely to find themselves in. It is definitely broken, but the breakage can often be worked around through prudent engineering. Anyway, a new post is coming soon with even more fun issues .

John

I see what you’re saying, but it essentially makes no difference. In this 2 line function, there is clearly a sequence point between the 2 instructions. Interpreting the spec such that the non-volatile access can move past a volatile access clearly invalidates it in all cases except 2 volatile accesses. In any case, if the volatile write is done before the array write, then the volatile instruction *has* moved past the sequence point before it.

An example, in {a;b;c;volatile;d;e;f;}, it’s fine to rearrange {a;b;c;} and {d;e;f;} at will, e.g. to produce {c;b;a;volatile;f;d;e}, but it is not correct to rearrange any of these statements outside of their triplet because doing so necessarily causes the volatile to move across a sequence point.

I guess it boils down, as you say, to whether a memory access is a side effect. Personally, I’d argue that it is a side-effect (and in fact, this causes the compiler no problems as it can still re-order any non-volatile statements), but if the accepted view is that this is wrong, then I guess it’s something we have to live with.

Certainly, I agree that compiler vendors are unlikely to change their implementations and that it’s best to highlight that this problem exists and work around it as you describe.

Ralf