Here's what the standard says (C99 6.7.3p6):
An object that has volatile-qualified type may be modified
in ways unknown to the implementation or have other unknown
side effects. Therefore any expression referring to such an
object shall be evaluated strictly according to the rules of
the abstract machine, as described in 5.1.2.3. Furthermore,
at every sequence point the value last stored in the object
shall agree with that prescribed by the abstract machine, except
as modified by the unknown factors mentioned previously. What
constitutes an access to an object that has volatile-qualified
type is implementation-defined.
with a footnote:
A volatile declaration may be used to describe an object
corresponding to a memory-mapped input/output port or an object
accessed by an asynchronously interrupting function. Actions
on objects so declared shall not be ‘‘optimized out’’
by an implementation or reordered except as permitted by the
rules for evaluating expressions.
On the other hand, if you just apply "volatile" to a local variable,
the compiler can reasonably know that there's no magic going on behind
the scenes. It's not clear whether the compiler is permitted to take
advantage of this knowledge; I'd say it probably isn't.
OK but is that footnote normative? I would be surprised if so.
It does appear that this is a gray area in the standard that needs
clarifying.
My suggestion would be to change the semantics of volatile for a local
(automatic) variable, to mean that accesses to the variable would be
guaranteed atomic (so the compiler would automatically insert a mutex to
protect accesses, if the variable's type cannot be accessed atomically on
the host architecture). Assuming that the C standard follows the next C++
standard in including multithreading support, this issue will have to be
addressed anyway, and using the already existing volatile keyword seems
to take care of this very neatly.
My $0.02...
