That's only the suggested overflow checking for a single operation. When you have multiple add/sub/mul/compare operations in a row, checking for actual overflow becomes quite non-trivial and is not something that can be done by the hardware. Floating point has no equivalent to this, which is why it makes sense to have overflow checking as part of the instruction.

I don't understand what you are saying. An overflow in an intermediate result should signal an overflow unless you're relying on some special property of 2's complement arithmetic in which case you should be using specific datatypes to suppress the check. All I'm saying about floating point is that the presence of overflow checking in high performance FPU's falsifies (afaict) the claim that it's unfeasible to do the same thing for integers.

  > FPU's falsifies (afaict) the claim that it's unfeasible to do the same thing for integers.

was the argument that its unfeasible or that just not doing it is a net win?

Even better to have a 'trap on integer overflow' state (either a bit in each instruction or in a context register), this way there's no/less icache impact.

> 1) it looks a lot worse than 1%

The 9% / 28% are for -fsanitize=signed-integer-overflow,unsigned-integer-overflow, which prints a warning on overflow.

The version with -fsanitize-undefined-trap-on-error, which aborts the process, only causes a slowdown of 0-1%.