[llvm] Revert "[SimplifyCFG] Deduce paths unreachable if they cause div/rem UB" (PR #137741)

Bill Wendling via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 29 11:25:33 PDT 2025


bwendling wrote:

> > @nikic and @dtcxzyw, since you both NACK'ed this patch, please offer a way to address this issue rather than using hidden flags. This issue is not simply a Linux kernel issue. It may happen to anyone who uses Clang. So I'd like to know the best way to address this.
> 
> The best solution is to avoid UB in your code.

Seriously?! This isn't an appropriate response. I'm not joking here. I need you to offer up a real way to address this issue.

> As I said before, you cannot expect a trap to be triggered when division by zero happens (e.g., on RISC-V platforms). If you need a trap, please add an explicit check and use `__builtin_trap` (or compile your code with `-fsanitize=integer-divide-by-zero`).

Whether a trap or signal or whatever happens with divide by zero doesn't matter. The point of reverting the patch is to prevent incorrect, and potentially dangerous, code from being emitted.

> For the second comment [#137741 (comment)](https://github.com/llvm/llvm-project/pull/137741#issuecomment-2837179510), I am okay to add a flag to insert a `__builtin_trap` before each `__builtin_unreachable` introduced by the optimizer. There is a balance between safety and performance.
> 
> > From what Linus commented, it looks like Clang isn't honoring unreachable code, and will generate some instructions after it. In the specific case, the panic() call, which is marked "noreturn".
> 
> Please file a separate issue :)

Okay, you're not taking this seriously. If you're not going to give constructive feedback, then please remove yourself from the reviewers list.

https://github.com/llvm/llvm-project/pull/137741


More information about the llvm-commits mailing list