[llvm-bugs] [Bug 30708] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=30708

Davide Italiano <davide at freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Davide Italiano <davide at freebsd.org> ---
This code exhibits undefined behaviour.

Just before instcombine (but after inlining and other many passes) main()
contains the following basica block:

.split:                                           ; preds = %0
  %cmp.i.us20 = icmp ugt i32 53, 1
  %shr.i.us21 = lshr i32 1, 53
  %cmp624.i.us22 = zext i1 %cmp.i.us20 to i32
  %conv4.i.us23 = or i32 %cmp624.i.us22, %shr.i.us21
  %. = select i1 %tobool8.us46.i, i32 0, i32 1
  store i32 1, i32* @c, align 4
  store i32 %., i32* @a, align 4
  store i32 %conv4.i.us23, i32* @b, align 4
  %tmp = load i32, i32* @b, align 4
  call void (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x i8]*
@.str, i32 0, i32 0), i32 %tmp)
  ret void

This instruction:
  %shr.i.us21 = lshr i32 1, 53
has UB as we're trying to shift right > 32, that gets folded into `undef` by
instcombine, and the next `or i32 %cmp624.i.us22 undef` gets in turn folded
into -1. That's the `-1` value that's subsequently stored, loaded, and printed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161020/8b9e242c/attachment.html>