Question

In C++03 Standard observable behavior (1.9/6) includes reading and writing volatile data. Now I have this code:

int main()
{
    const volatile int value = 0;
    if( value ) {
    }
    return 0;
}

which formally initializes a volatile variable and then reads it. Visual C++ 10 emits machine code that makes room on the stack by pushing a dword there, then writes zero into that stack location, then reads that location.

To me it makes no sense – no other code or hardware could possibly know where the local variable is located (since it’s in automatic storage) and so it’s unreasonable to expect that the variable could have been read/written by any other party and so it can be eliminated in this case.

Is eliminating this variable access allowed? Is accessing a volatile local which address is not known to any other party observable behavior?

Answer 1

The thread’s entire stack might be located on a protected memory page, with a handler that logs all reads and writes (and allows them to complete, of course).

However, I don’t think MSVC really cares whether or how the memory access might be detected. It understands volatile to mean, among other things, “do not bother applying optimizations to this object”. So it doesn’t. It doesn’t have to make sense, because MSVC is not interested in speeding up this kind of use of volatile.

Since it’s implementation-dependent whether and how observable behavior can actually be observed, I think you’re right that an implementation can “cheat” if it knows, because of details of the hardware, that the access cannot possibly be detected. Observable behavior that has no physically-detectable effect can be skipped: no matter what the standard says, the means to detect non-conforming behavior are limited to what’s physically possible.

If an implementation fails to conform to the standard in a forest, and nobody notices, does it make a sound? Kind of thing.