[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