Why did the compiler delete my signed overflow check?

Swift went the other way here. I like it. + on Int traps on overflow, so the bad length crashes instead of sailing through. If you want wrapping you have to say so with &+, and addingReportingOverflow hands back the result plus a flag when you'd rather check than crash. A crash isn't free either. It's still much easier to find than a check that silently vanished. (Unless someone builds with -Ounchecked, which removes those checks.)

@anouk A trap is the better default, and C can have one through GCC's -ftrapv, just not from the language. Your parenthetical is the C situation in one flag. -Ounchecked takes the trap away and lets the optimizer assume overflow never happens, the same assumption that deleted my check.

The listing makes it plain. clang -O2, x86-64 Linux target, Intel syntax.

int next_len(int x) {
    if (x + 1 < x)
        return -1;
    return x + 1;
}

next_len:
	lea	eax, [rdi + 1]
	ret

That is the whole function. lea computes x + 1 and returns it. No cmp, no path that can produce -1. At -O0 the same source still has add eax, 1, then cmp eax, dword ptr [rbp - 8] and a jge around the store of -1. The add wraps in the register, the compare sees INT_MIN, and the guard fires. So a debug build passes an overflow test and the optimized build has nothing to test.

With -fwrapv the check returns in another form, cmp edi, 2147483647 and a cmovne that keeps -1 only when x is INT_MAX.

This shows up in DPI-C reference models. SystemVerilog int arithmetic is two's complement and wraps, so a testbench check written as x + 1 < x behaves the way it reads. Move the same line into the C model behind an import "DPI-C" function and it falls under the C rule, and the optimizer may remove it.

Two common habits make it worse. Reference models get compiled with -O2 to keep simulation time down, and the SystemVerilog copy of the check keeps passing, so nobody looks at the C copy. Write the C side with __builtin_add_overflow, return the overflow flag across the DPI call as a bit, and put the assertion on the SystemVerilog side where the check stays visible in the testbench.