The compiler has to assume that I+10 won’t overflow by virtue of I never being big enough. So, it’ll emit all of the code and UB won’t come into play. It’s mor

The compiler has to assume that I+10 won’t overflow by virtue of I never being big enough. So, it’ll emit all of the code and UB won’t come into play. It’s more like this. If you say A[I] where I is 32 bit signed and you’re on a 64 bit target, then this lowers to: - sign extend I to get a 64-bit value - multiply it by the size of A’s element type - add that to A - then do the access The last three steps will be just one instruction in the common case on arm and x86. The first step will require a separate instruction on x86. The compiler can kill the sign extend if it’s sure that the integer value cannot be negative. That’s hard to prove. But you can almost prove it if you see code like: for (int i = 0; something; ++i) It looks like i starts out as zero and only grows! So it has to be positive! So if you say A[i] then no sign extend needed! But wait, what if ++i overflows? With signed int UB, the compiler can just assume it won’t overflow. And then it can prove that i is nonnegative. And then it can kill the sign extend on those CPUs where it’s not free, like x86. I’m a compiler writer. I know how valuable this optimization is. Namely, it’s the tiniest of benefits on some program/CPU combos. Modern languages like Java or Swift just give this well defined semantics and call it a day because this isn’t a good hill to die on. Fucking up the language isn’t worth 0.3% on some stupid benchmark, period.