Can an ANSI C compiler remove a delay loop?

Question

Consider a while loop in ANSI C whose only purpose is to delay execution:

unsigned long counter = DELAY_COUNT;
while(counter--);

I've seen this used a lot to enforce delays on embedded systems, where eg. there is no sleep function and timers or interrupts are limited.

My reading of the ANSI C standard is that this can be completely removed by a conforming compiler. It has none of the side effects described in 5.1.2.3:

Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment.

...and this section also says:

An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).

Does this imply that the loop could be optimised out? Even if counter were volatile?

Notes:

1. That this is not quite the same as Are compilers allowed to eliminate infinite loops?, because that refers to infinite loops, and questions arise about when a program is allowed to terminate at all. In this case, the program will certainly proceed past this line at some point, optimisation or not.
2. I know what GCC does (removes the loop for -O1 or higher, unless counter is volatile), but I want to know what the standard dictates.

Answer 1

C standard compliance follows the "as-if" rule, by which the compiler can generate any code that behaves "as if" it was running your actual instructions on the abstract machine. Since not performing any operations has the same observable behaviour "as if" you did perform the loop, it's entirely permissible to not generate code for it.

In other words, the time something takes to compute on a real machine is not part of the "observable" behaviour of your program, it is merely a phenomenon of a particular implementation.

The situation is different for volatile variables, since accessing a volatile counts as an "observable" effect.