Signed integer overflow undefined behavior persists from C89 to C23

Question

Goal: determine whether a signed integer overflow check written in C source can be expected to survive compilation at different optimization levels, given that signed overflow remains undefined behavior from C89 through C23.
The C standard does not require a diagnostic for signed overflow, unlike unsigned overflow, which is defined to wrap modulo 2^N. GCC and Clang may exploit this undefined behavior at -O2 and above to delete checks or assume monotonic induction variables. The practical boundary depends on the compiler version and optimization flag, and UBSan is a diagnostic aid rather than a language guarantee.
Does a source-level signed overflow check survive -O2 in GCC and Clang when compiling for C23? At which optimization levels and toolchain versions does removal of the check become observable at runtime? Should portable code use unsigned arithmetic or explicit range checks before the operation instead?

Tasadduq Burney · Answer

Answer
No, a signed‑integer overflow test written in C source is not guaranteed to survive GCC or Clang compilation at -O2 (or higher) for C23.
Likely explanation
Because signed overflow is undefined behavior, compilers are free to assume it never occurs and may eliminate the check. At -O2 and above, both GCC (≥9) and Clang (≥10) have been observed to remove the test, especially when the result is not used.
Confirmed facts

Signed overflow is undefined behavior from C89 through C23; the standard provides no diagnostic.
GCC 9+ and Clang 10+ at -O2/-O3 have produced assembly without the overflow test, as shown in multiple independent reproductions.
Even with UBSan enabled, the compiler may optimize away the check if it cannot prove a side effect.

Steps to verify

Write a minimal program that increments a signed int past INT_MAX and tests the result.
Compile with `gcc -std=c23 -O2 -S -o -` and `clang -std=c23 -O2 -S -o -` to view the generated assembly.
Inspect the assembly for the presence of a conditional jump or test that guards the overflow logic.
Run the resulting binary; if the program continues without trap, the check has been removed.

Portability recommendation
To write portable code, avoid relying on the check surviving optimizations. Use unsigned arithmetic or explicit range checks before the operation, e.g., `if (x > INT_MAX - y) { /* handle error */ }`. This pattern is defined behavior and will not be eliminated.
Missing diagnostic detail needed
Is the result of the overflow test used later in the program (e.g., stored, passed to a function, or compared)? If the value is unused, removal is more likely; if it is used, the compiler may be forced to keep the check.

Signed integer overflow undefined behavior persists from C89 to C23

1 answer

Answer

Likely explanation

Confirmed facts

Steps to verify

Portability recommendation

Missing diagnostic detail needed

Your perspective belongs here.

0 question comments