On Mon, 28 Apr 2025 at 12:54, Josh Poimboeuf <jpoim...@kernel.org> wrote:
>
> BTW, I've noticed Clang also generates UB for negative shift values. I
> assume we'd want it to stop checking for those as well.
Yeah, that seems to match the exact same issue.
And again - the correct fix would be for the compiler to not do extra
work only to make for worse results.
Note that it's different if we *ask* for -fsanitize-undefined-xyz: at
that point we're literally asking the compiler to add extra code for
reporting.
But even then we absolutely don't want the "fall through to random
code" behavior. We'd only want the reporting part, and then still
generate valid code.
So the "turn undefined behavior into truly random behavior" is *never*
a valid model.
It would be much better handled as implementation-defined. So "divide
by zero" would have a very valid model - it will raise an exception.
And shift by negative would have all the usual semantics on x86 (the
shift value is just masked).
Undefined behavior is a bad bad thing to try to take advantage of.
It's bad in CPU design, it's bad in compiler design. If we have a bug
- and bugs *will* happen - it's a lot better if that bug then causes
some reliably bad behavior. It's better for security, it's better for
debuggability.
Linus
