You are still missing the point. Yes, compilers obviously should not intentionally produce unnecessarily destructive behaviour. But that is not what is happening. What if the code contains &quot;x&#x2F;y&quot;? Now, the compiler can try to prove that x and y can never be 0 at the same time. But what if that proof doesn&#x27;t succeed? Maybe x is user input, so who knows what the user will enter at runtime? Now, the language spec could specify that the computation of 0&#x2F;0 always results in a runtime error. But if it did that, there might be target architectures where the code that would need to be generated to check for that case would have a 300% performance overhead versus code that does unpredictable stuff when it gets fed 0 for both x and y, but in every other case performs a perfectly predictable division. That slowdown would be inacceptable for computation-intensive code where a 0&#x2F;0 could never happen by construction, even though the compiler can&#x27;t prove it. And that is why the standard simply says &quot;it&#x27;s undefined behaviour&quot;.