Tracking issue for LLVM 6 upgrade

[alexcrichton]

An LLVM release candidate for 6.0.0 has been tagged, and despite not having upgraded to LLVM 5 we should start weeding out bugs for LLVM 6!

• https://github.com/alexcrichton/rust/tree/llvm-6
• https://github.com/alexcrichton/llvm/tree/rust-llvm-release-6-0-0
• https://github.com/alexcrichton/compiler-builtins/tree/llvm-60
• https://github.com/rust-lang/compiler-rt/tree/rust-llvm-release-6-0-0

test results:

• Second Travis Run
• First Travis Run

Issues with no diagnosis/resolution

• None!

I'm sure this list will expand over time! I'll try to keep it updated.

Issues with a diagnosis/resolution that hasn't landed

• i686 MSVC is showing a corrupt rlib when linking, something about archive writing changed maybe?
  • appears to be an LLVM regression
  • local hack reverting the line in that linked commit seems to fix the issue
• Emscripten needs an upgrade
  • hopefully obviated by Implement shipping a per-target LLVM backend #46819

Fixed issues:

• LLVM removed CodeModel::Default, it's now optional - First round of LLVM 6.0.0 compatibility #47710

• The MIPS64 archive variant was renamed - First round of LLVM 6.0.0 compatibility #47710

• UnsafeAlgebra support has been refactored - First round of LLVM 6.0.0 compatibility #47710

• Return value of writeArchive has changed - First round of LLVM 6.0.0 compatibility #47710

• wasm32-unknown is showing DICompileUnit assertions, we probably need to apply the same fix that ThinLTO has already. - First round of LLVM 6.0.0 compatibility #47710

• wasm32's dlmalloc needs updating as an intrinsic changed (there's an llvm5 branch in the dlmalloc repo)

• Sanitizers need updating as x86_64-gnu is failing (compiler-builtins has an llvm6 branch)

• Our FreeBSD x86_64 image fails to compile LLVM 6 - First round of LLVM 6.0.0 compatibility #47710

• Lingering debuginfo failure affects LLVM 5 as well - Let LLVM 5 add DW_OP_deref to indirect args itself #47688

• Our FreeBSD i686 image fails to compile LLVM - for now hack around this

• arm-android has weird floating point failures that suggests a compiler-rt mismatch

  • looks like this isn't caused by LLVM updates, but rather Implement comparesf2/comparedf2 intrinsics compiler-builtins#222
  • that'll get resolved by either backing it out or fixing it to land locally
  • fixed in Fix some typos/bugs with float comparison intrinsics compiler-builtins#224

• x86_64/i686 linux dist builders can't compile newer compiler-rt (sanitizers presumably)

  • random hack to fix this

• armhf-gnu has a few SIGSEGV in the test suite of run-fail, something about unwinding may be busted

  • appears to be an LLVM regression
  • fix proposed at https://reviews.llvm.org/D42509

PRs:

• Initial pass for upgrading in-tree support for LLVM 6
• First round of compat
• Fix DW_OP_deref support (affects LLVM 5 as well)

[alexcrichton]

The most recent Travis run is now all green. I've manually tested on OSX locally and we're all good there, and we're also good on MinGW Windows. The last remaining bug is the MSVC archive regression. Still hunting that down.