[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow

["i at maskray dot me" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at maskray dot me

--- Comment #13 from Fangrui Song <i at maskray dot me> ---
I see a Clang patch that proposes -fsanitize=signed-integer-wrap, which appears
to be the same as signed-integer-overflow, but performs the check in the
-fwrapv mode.

I feel that it's better to make -fsanitize=signed-integer-overflow work with
-fwrapv
https://github.com/llvm/llvm-project/pull/80089#issuecomment-1945202620

--- Copying here for folks prefer not to read github

This is a UI discussion about how command line options should behave.
Some folks prefer simpler rules while some prefer smart rules (guessing user
intention).

A
[-fwrapv](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fwrapv)
user may either:

* rely on the wraparound behavior
* or prevent certain optimizations that would raise security concerns

Our -fsanitize=signed-integer-overflow design have been assuming that -fwrapv
users don't need the check.
This PR suggests that an important user does want overflow checks and our guess
has failed.
It seems very confusing to have two options doing the same thing.

https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html is clear that not
all checks are undefined behavior in the standards.

> Issues caught by this sanitizer are not undefined behavior, but are often unintentional.

Sure -fwrapv makes wraparound defined, but it doesn't prevent us from making
-fsanitize=signed-integer-overflow useful. "-fwrapv => no
signed-integer-overflow" is not a solid argument.

I think we can try making -fsanitize=signed-integer-overflow effective even
when -fwrapv if specified.
-fsanitize=signed-integer-overflow is rare in the wild, probably rarer when
combined with -fwrapv.

There is a precedent that -fsanitize=undefined enables different checks for
different targets.
We could make -fsanitize=undefined not imply -fsanitize=signed-integer-overflow
when -fwrapv is specified, if we do want to guess the user intention.
Personally I'd prefer moving away from such behaviors and be more orthogonal.