Bug ID: 36386
           Summary: JumpThreading misoptimization, only on glibc 2.26
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations

Hello! Over at rust-lang/rust we've recently upgraded to LLVM 6.0 (yay!) but
unfortunately have had a bit of a rocky time since then. We've been having
CI runs [1] that are spuriously failing on various platforms. This has been
notoriously difficult to reproduce so far, but I think we've started making
great progress!

This bug originally surfaced as a presumed miscompilation of rustc itself,
although I believe we've reduced it down to a much smaller test case at this
point. The odd part about this reproduction is it depends on whether LLVM, as
it's running, is using glibc 2.26 or not. When using glibc 2.26 a
occurs, and when using glibc 2.25 or prior the miscompilation does not occur.

I've personally been completely baffled by what's going on here. Valgrind
reported much suspicious unfortunately. The one thing it did report, a
conditional jump on uninitialized memory, was diagnosed [2] as a spurious error
that likely isn't the root cause.

My local machine has glibc 2.23 installed, and I've been using Docker to
Ubuntu 18.04 and get glibc 2.26. I've been compiling LLVM locally with
assertions enabled and in release mode using Clang 4 as a compiler. Using the
same `opt` binary from this build (which was built against glibc 2.23) I then
get different results optimizing the input IR [3] depending on whether it runs
on Ubuntu 16.04 (glibc 2.23) or Ubuntu 18.04 (glibc 2.26). The output of each
run and their diff is here -- [4].

Jun I've cc'd you because when I ran a bisection on this error I was seeing it
came up with as a culprit. Reverting that patch
does indeed seem to fix the behavior locally, although that patch also doesn't
seem like it's doing anything wrong so I'd suspect that this was an existing
perhaps. Would you be able to help us though in routing this to the proper

If any more information is needed please just let us know! I think we've worked
around this issue in our own builds for now at least so it's hopefully not 
pressing on our end any more, but this seems like it may be good to fix 


You are receiving this mail because:
You are on the CC list for the bug.
llvm-bugs mailing list

Reply via email to