An iteration statement whose controlling expression is not a constant expression, that
performs no input/output operations, does not access volatile objects, and performs no
synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate
“new Random().nextInt()” might perform I/O though so it could still be defined behavior. Or the compiler does not assume this assumption.
But an aggressive compiler could realize the loop would not terminate if x does not become 10 so x must be 10 because the loop can be assumed to terminate.
Not sure about the last one though. The other two are trivial to optimize away.
An infinite loop canot be ruled out in the last case, so a compiler couldn’t optimize this away without potentially changing the program behavior.
Infinite loops are often weird though. They could be seen as undefined behavior and the compiler may do whatever it feels like.
How could an infinite loop be considered UB?
Even though this isn’t C, but if we take from the C11 draft §6.8.5 point 6 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):
“new Random().nextInt()” might perform I/O though so it could still be defined behavior. Or the compiler does not assume this assumption.
But an aggressive compiler could realize the loop would not terminate if x does not become 10 so x must be 10 because the loop can be assumed to terminate.