"VOLATILE" IS VERY C0NFUSING

The part where it says that volatile makes the execution environment behave just like the language definition says the virtual machine will.

Actually, it doesn't say this. It says that that accesses to volatile objects will be made according to the rules of the abstract machine. And, according to the standard, 'What constitutes an access to an object that has volatile-qualified type is implementation-defined.'

At every sequence point, the value of every variable in the program has to be in exactly the state defined by the language and the source code.

Exactly. But that doesn't prevent the compiler from eliminating empty loops, despite the fact that the loop has a number sequence points, and variables modified between those points.
Another thing: how can the values of those variables be observed? They can only be observed through the actions of that same program. The debugger doesn't count, the standard does not mention it.
In Andy's example, it is clear that the volatile variable cannot affect anything, and the compiler can easily deduce this. So a minor clause in the 'implementation-defined behaviour' will allow the compiler to eliminate the loop, thus producing more efficient code.

The part where it says that volatile makes the execution environment behave just like the language definition says the virtual machine will.

Actually, it doesn't say this. It says that that accesses to volatile objects will be made according to the rules of the abstract machine. And, according to the standard, 'What constitutes an access to an object that has volatile-qualified type is implementation-defined.'

At every sequence point, the value of every variable in the program has to be in exactly the state defined by the language and the source code.

Exactly. But that doesn't prevent the compiler from eliminating empty loops, despite the fact that the loop has a number sequence points, and variables modified between those points.
Another thing: how can the values of those variables be observed? They can only be observed through the actions of that same program. The debugger doesn't count, the standard does not mention it.
In Andy's example, it is clear that the volatile variable cannot affect anything, and the compiler can easily deduce this. So a minor clause in the 'implementation-defined behaviour' will allow the compiler to eliminate the loop, thus producing more efficient code.

If I wrote a compiler, I would be inclined to think that it would be ok to remove the loop, since writes to an auto variable can have no side effets - besides overflowing a too small stack, or producing non-productive bus accesses.

But I don't think I have seen any compiler who will remove the loop if the variable is volatile.

Probably, as Mike suggests, the letter of the law would permit the compiler to optimise-out such loops.

In practice, compiler writers - especially embedded compiler writers - probably realise that their customers do make use of such loops, and so they choose not to.

In practice, compiler writers - especially embedded compiler writers - probably realise that their customers do make use of such loops, and so they choose not to.

Actually, I prefer it this way too: better safe than sorry. It's probably possible to take the spec to such an extreme that the resulting compiler wouldn't be useful for much of anything.
It reminded me of this thread on the Linux kernel mailing list:
kerneltrap.org/.../359162

Another thing: how can the values of those variables be observed? They can only be observed through the actions of that same program.

This argument, essentially a subset of the "as-if" rule, holds for normal variables, but not for volatile-qualified ones. Forbidding application of the as-if rule is exactly what volatile is about. Following your line of reasoning, volatile might as well imply static duration, since it doesn't have any effect on automatic variables.

Also note C99 5.1.2.3: writes to volatile objects are side-effects, and as such they have to be completed before the next sequence point. I rather much doubt that the seeming loop-hole 6.7.3p6 about implementation-definedness of "access to a volatile object" should be understood to cover writing a value to it. Particularly as it stands after a clause of the pattern "except ... as mentioned previously"

In practice, compiler writers - especially embedded compiler writers - probably realise that their customers do make use of such loops, and so they choose not to.

Optimising away writes to a volatile variable would always be at least a straight violation of the programmer's expressed will, even if the standard can be bent into seemingly allowing it.

Even setting aside volatile, the GCC guys have a particularly clever idea about optimizing away entire loops: if a non-empty loop body was optimized away, the loop itself is removed, too. If the loop body was empty in the first place, they leave the entire loop alone, under the assumption that nobody would write an empty loop lest they really mean it.

It seems to depend a lot on gcc version. Most probably, only versions before 4.x keep empty loops.

Test with empty loop and -O3:

gcc 2.95.4 leaves loop.
gcc 3.0.4 leaves loop.
gcc 3.3.1 leaves loop.
gcc 3.3.5 leaves loop.
gcc 3.3.6 leaves loop.
gcc 4.1.2 strips loop.