Dead Code Elimination can even optimise out blocking loops, a loop like for(;;) can be optimised out.
Why: Computationally, there is no difference between "no code" and "a loop that iterates 100 times and does nothing". It is thus correct to eliminate the latter to preserve the observable behaviour. However, a loop that never terminates is a very different thing entirely: it says "execution will never progress past this point" and everything afterwards will never be reached. This property is so enshrined in theoretical computer science that any half-decent verification tool will consider what comes after the loop as dead code and not check it. In the newer GCC and Clang the code after a never-ending loop will be marked "unreachable" and be killed as dead code.
So removing a never-ending loop would be quite the big deal indeed.
Technical note: specifically in C and C++ and every language implemented using them, a loop with a counter but no check on the upper bound (eg. "for(i = 0; ; ++i)" ) is very different from the empty loop discussed above. Such a loop would be called "undefined behavior": the program may or may not stop, the world may explode, etc. This is because C and C++ say that overflow has undefined behavior. So this kind of loop does not mean "the programmer intends the control flow to terminate here", but rather "the programmer is playing with fire and it can burn".
There is a part of the C++ standard that says something along the lines of: the compiler may assume that every program will eventually exhibit some side-effect. That part of the standard also explicitly states that this is intended to allow compilers to remove loops with empty bodies (or bodies with only dead code) even if they cannot prove termination of the loop. See e.g. page 14 of http://isocpp.org/files/papers/N3690.pdf
This is certainly useful when you think of code that is created indirectly via macros and/or template instantiation. Whether compilers actually perform this "optimization" on explicit endless loops like for(;;); is another question, but at least C++ can claim to be able to run certain endless loops in under a second ;)
Then the initial discussion above was about C, and the ISO C standard does not contains words to that effect at all.
Probably the most common (or at least my favorite) example of DCE leading to a surprise, is when embedded programmers use so-called "delay loops" which can be eliminated by the compiler because it too is "empty" (the loop produces nothing that is used outside of the loop).
Essentially, C++ does not consider looping forever to be a side effect. You have to do something like writing to a volatile variable to ensure that the compiler does what you want.
"The implementation may assume that any thread will eventually do one of the following: — terminate, — make a call to a library I/O function, — access or modify a volatile object, or — perform a synchronization operation or an atomic operation. [ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note ]"