ypig:~> clang --version Debian clang version 3.4-1 (trunk) (based on LLVM 3.4) Target: x86_64-pc-linux-gnu Thread model: posix ypig:~> cat tst.c #include <stdio.h> int main (void) { volatile int i, t = 0; volatile double x; double z = 0.0; i = t ? 0 / 0 : 0; printf ("[1] %d\n", i); x = t ? z / z : z; printf ("[2] %g\n", x); x = t ? 0.0 / 0.0 : 0.0; printf ("[3] %g\n", x); return 0; } ypig:~> clang -fsanitize=undefined tst.c -o tst tst.c:9:13: warning: division by zero is undefined [-Wdivision-by-zero] i = t ? 0 / 0 : 0; ^ ~ 1 warning generated. ypig:~> ./tst [1] 0 [2] 0 tst.c:13:15: runtime error: division by zero [3] 0 but because t == 0, the 0.0 / 0.0 in the third test should never be evaluated. The first two tests are OK, so that it seems related to floating-point division with constants specifically. This bug yields a failure in the tget_flt test of the GNU MPFR trunk r8685 with: clang -O2 -fsanitize=undefined -fno-sanitize-recover
Weird. Here's the branch for the third conditional: %29 = load volatile i32* %t, align 4 %30 = icmp ne i32 %29, 0 br i1 false, label %32, label %31, !prof !0 That last line should be br i1 %30, label %31, label %32, !prof !0
This still reproduces for me.
Update here. Here's the problem: Clang sometimes emits a conditional_operator by emitting its left-hand side and right-hand side, followed by "select" instruction. Of course, it does so only in case when both sides are cheap to evaluate unconditionally, and evaluations are known to have no side effects. Well, they *do* have side effects if evaluation triggers UB *and* we are checking for it in UBSan. Richard tells that he is working on a fix for expression constant evaluator to handle this properly.
Fixed in r254574.