Rust: LLVM 5.0 Tracking Issue

[TimNN]

The time has come again, LLVM is releasing 5.0 soon and Rust wants to / needs to follow.

I have started work on the upgrade in these branches:

• rust-lang/rust: https://github.com/alexcrichton/rust/tree/llvm50
• rust-lang/llvm: https://github.com/rust-lang/llvm/tree/rust-llvm-2017-07-20
• rust-lang/compiler-rt: https://github.com/rust-lang/compiler-rt/tree/rust-2017-07-20
• rust-lang-nursery/compiler-builtins: https://github.com/rust-lang-nursery/compiler-builtins/tree/llvm50

Open tasks

• [ ] get asm.js working again - reenable JSBackend as a target
  
  
  
  • [x] add asm.js target to our fork - https://github.com/rust-lang/llvm/commit/c9a21231adee1733a9ae5b2ba8c15c37576282a5
  
  
  • [ ] [update emscripten to LLVM 5.0](https://github.com/kripken/emscripten-fastcomp/issues/193)
  
  

Completed tasks

Next steps:

• [x] Get rustllvm to compile (error log)

Current issues:

• [x] A lot changed around attributes (#43387)
• [x] SynchronizationScope changed / was renamed? (#43387)
• [x] LLVMMetadataRef was added, this can / should likely replace LLVMRustMetadataRef (#43387)
• [x] createPointerType gained a new parameter (#43387)
• [x] createNameSpace lost some parameters (#43387)
• [x] DebugLoc was replaced by DiagnosticLocation in LLVM DiagnosticInfo (#43387)
• [x] compiler segfault when testing in stage2 - using x86_64-gnu image
  
  
  
  • [x] [sample backtrace](https://gist.github.com/alexcrichton/9a2135eb5b99f10426cd6e017d7e8597)
  
  
  • [x] [upstream bug](https://bugs.llvm.org/show_bug.cgi?id=33917)
  
  
  • [x] upstream fix (temporary workaround) - commit1, commit2
  
  
• [x] fix compilation of fuzzer on various platforms
  
  
  
  • [x] [i686 freebsd](https://travis-ci.org/rust-lang/rust/jobs/257578198)
  
  
  • [x] [x86_64 freebsd](https://travis-ci.org/rust-lang/rust/jobs/257578208)
  
  
  • [x] [x86_64 netbsd](https://travis-ci.org/rust-lang/rust/jobs/257578212)
  
  
  • [x] upstream bug local fix/workaround
  
  
  • [x] upstream fix
  
  
  • [x] https://github.com/rust-lang/rust/pull/43527
  
  
• [x] fix compilation of LLVM on i686-unknown-linux-gnu
  
  
  
  • [x] [logs](https://travis-ci.org/rust-lang/rust/jobs/257578199)
  
  
  • [x] upstream bug local workaround
  
  
  • [x] upstream fix
  
  
• [x] codegen/issue-37945.rs - info below
  
  
  
  • [x] [upstream bug](https://bugs.llvm.org/show_bug.cgi?id=33470)
  
  
  • [x] [upstream fix](https://reviews.llvm.org/D36590) (ignore it)
  
  
• [x] FreeBSD failed to compile std::to_string references
  
  
  
  • [x] https://github.com/rust-lang/rust/pull/43530
  
  
• [x] fix run-make/sanitizer-leak - apparently hit a fatal error when run locally?
  
  
  
  • [x] --privileged needed when running the docker container https://github.com/rust-lang/rust/pull/43536
  
  
• [x] run-make/simd-ffi
  
  
  
  • [x] [upstream bug](https://bugs.llvm.org/show_bug.cgi?id=33883)
  
  
  • [x] [upstream fix](https://reviews.llvm.org/D35765)
  
  
• [x] mips failed to compile cargo
  
  
  
  • [x] [mipsel logs](https://travis-ci.org/rust-lang/rust/jobs/257578203)
  
  
  • [x] [mips logs](https://travis-ci.org/rust-lang/rust/jobs/257578200)
  
  
  • [x] [upstream bug](https://bugs.llvm.org/show_bug.cgi?id=33978)
  
  
  • [x] [upstream fix](https://reviews.llvm.org/D36236)
  
  
• [x] related debuginfo-gdb test failures - #47610
  
  
  
  • sample fix
  
  
  • explanation
  
  
  • [x] rustc with LLVM 5 reports invalid DIExpression (#47464) - fixed in #47610
  
  
  • [ ] LLVM 5 fails debuginfo/by-value-self-argument-in-trait-impl.rs (#47611)
  
  

All but the first issues seem straight forward to fix, so I'll try to send PRs for those soon.

[TimNN]

cc @nagisa, @michaelwoerister, @arielb1, @eddyb: You have been recommend as familiar with the rust llvm wrapper, would one of you mind looking into the attributes changes?

[alexcrichton]

With #43387 looks like rustc can bootstrap on x86_64-unknown-linux-gnu, but there's a lot of test failures. A full stage2 test run has tons of errors, lots of compiler segfaults. A stage1 test run has much fewer errors:

test [compile-fail] compile-fail/proc-macro/derive-bad.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/expand-to-unstable-2.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/expand-to-unstable.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/issue-38586.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/item-error.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/lints_in_proc_macros.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/proc-macro-attributes.rs ... FAILED
test [codegen] codegen/lifetime_start_end.rs ... FAILED
test [codegen] codegen/issue-37945.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/var-captured-in-nested-closure.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/var-captured-in-sendable-closure.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/var-captured-in-stack-closure.rs ... FAILED
test [run-make] run-make/llvm-pass ... FAILED
test [run-make] run-make/rustc-macro-dep-files ... FAILED
test [run-make] run-make/simd-ffi ... FAILED
test [run-pass] run-pass/debuginfo-lto.rs ... FAILED
test [run-pass] run-pass/issue-34569.rs ... FAILED
test [run-pass] run-pass/backtrace.rs ... FAILED
test [run-pass] run-pass/backtrace-debuginfo.rs ... FAILED
test [run-pass] run-pass/proc-macro/add-impl.rs ... FAILED
test [run-pass] run-pass/proc-macro/append-impl.rs ... FAILED
test [run-pass] run-pass/proc-macro/attr-args.rs ... FAILED
test [run-pass] run-pass/proc-macro/bang-macro.rs ... FAILED
test [run-pass] run-pass/proc-macro/count_compound_ops.rs ... FAILED
test [run-pass] run-pass/proc-macro/crate-var.rs ... FAILED
test [run-pass] run-pass/proc-macro/derive-same-struct.rs ... FAILED
test [run-pass] run-pass/proc-macro/issue-40001.rs ... FAILED
test [run-pass] run-pass/proc-macro/issue-39889.rs ... FAILED
test [run-pass] run-pass/proc-macro/hygiene_example.rs ... FAILED
test [run-pass] run-pass/proc-macro/use-reexport.rs ... FAILED
test [run-pass] run-pass/proc-macro/load-two.rs ... FAILED
test [run-pass] run-pass/issue-40663.rs ... FAILED

[alexcrichton]

@eddyb indicated on IRC that this function call may be responsible for the debuginfo-gdb failures, and he was spot on!

[alexcrichton]

I've filed https://bugs.llvm.org/show_bug.cgi?id=33883 related to the run-make/simd-ffi failure

[eddyb]

So LLVM got even worse (the current implementation sometimes creates an alloca to avoid pretty much this kind of misoptimization ruining complex llvm.dbg.declare).

The proper solution here at this point is to produce a pointer to every single closure capture (which means loading the respective pointer from the environment, if the capture is already by-ref), and then use llvm.dbg.value to indicate that... oh, wait, that won't work, let me step back.

Using llvm.dbg.declare once means that even if the value is modified later, a debugger knows where to get the value during the scope the name is defined for.
OTOH, llvm.dbg.value gives the value at that time, and even if you say the value is behind a pointer, that won't let the debugger see updated values from later writes to the same location.

Which means we need one alloca for every single capture (holding the pointers mentioned above). This is because of idiosyncratic LLVM limitations - even though there is a system for indicating multiple pointer offsets and dereferences to get from the argument to llvm.dbg.declare (or llvm.dbg.value) (a subset of "DWARF expressions"), and there's enough information to start from an arbitrary pointer on stack or in a register (for llvm.dbg.value), analloca is still required.

But with one llvm.dbg.declare per alloca, they should be simple enough not to break.

[alexcrichton]

The codegen/issue-37945.rs failure looks related to https://github.com/rust-lang/llvm/pull/90. @arielb1 would you be able to help out diagnosing this one? I've verified that the llvm branch we have for 5.0 does indeed include those commits:

• https://github.com/rust-lang/llvm/commit/7df06519765b14e1b08d7034c82c45a0a653eb25
• https://github.com/rust-lang/llvm/commit/156cc49e505986a1659adaa3a0b5a070372377c8
• https://github.com/rust-lang/llvm/commit/477bd758b48cb96477d3dd4cf3b36bf2706e8c1d
• https://github.com/rust-lang/llvm/commit/5a057dc8edbb63887f8c611dd8ddf1b76997f07c
• https://github.com/rust-lang/llvm/commit/2b66aeed20b61d42cd2782b94d5419c6faca49a1

Do you think that this may have regressed in upstream LLVM?

[alexcrichton]

I think I fixed codegen/lifetime_start_end.rs in https://github.com/rust-lang/rust/pull/43387/commits/38e40ce50653b8164915b8142e883c5a57b33e7b

[TimNN]

Edit: Nevermind this comment, those tests are expected to fail on stage 1.

Original comment

For a stage 1 test run, I get the same failures as @alexcrichton, for compile-fail proc macro derive:

thread '<unnamed>' panicked at 'proc_macro::__internal::with_sess() called before set_parse_sess()!', /home/logic/build-tmp/rust-src/src/libproc_macro/lib.rs:678:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.
fatal runtime error: failed to initiate panic, error 5

full logs

I'm not sure about the initial panic message, but the "failed to initiate panic" seems kind of bad (error 5 is apparently _URC_END_OF_STACK)

For run-pass proc-macro-derive:

index out of bounds: the len is 0 but the index is 4294967206

That also seems bad.

[alexcrichton]

@TimNN oh no need to worry about those, that's a benign failure. Procedural macros don't work in stage1 and not all tests are flagged as // ignore-stage1

[alexcrichton]

Filed an upstream bug for the segfaults in rustc I've been seeing. (segfaults were happening on all platforms)

[arielb1]

The codegen/issue-37945.rs failure looks related to rust-lang/llvm#90. @arielb1 would you be able to help out diagnosing this one? I've verified that the llvm branch we have for 5.0 does indeed include those commits:

Sure. That's probably https://bugs.llvm.org/show_bug.cgi?id=33470

[alexcrichton]

Ok thanks @arielb1! Do you think it'd be safe to ignore that test during the LLVM upgrade in favor of that upstream bug? Or do you think we should block the upgrade on fixing that?

[arielb1]

The bug looks quite bad. Let's ignore it for now to see all the other bugs. I bet I can get it fixed first.

[alexcrichton]

This tree of commits passes ./x.py test on x86_64-unknown-linux-gnu with LLVM assertions enabled.

[alexcrichton]

I've done a full travis run against a tree with a number of workarounds, and I believe all open issues are listed under "Open Tasks" above.

[alexcrichton]

@eddyb commenting out the call site you indicated fixes the debuginfo related asserts in LLVM, but it doesn't actually cause any tests in Rust to fail. Do you know of an example of a test that would fail if we don't emit that debuginfo?

[eddyb]

@alexcrichton Erm, that means we don't have tests for closures... without that call no closure captures can be seen from a debugger as a local variable (from within the closure body).
cc @michaelwoerister

[michaelwoerister]

We actually do have a few test cases for captured variables, e.g. https://github.com/rust-lang/rust/blob/master/src/test/debuginfo/var-captured-in-stack-closure.rs.

[dvc94ch]

Any chance this is related? I tried building against llvm master then thought it was an issue caused by llvm >=5.

invalid expression
!12029 = !DIExpression(6, 34, 0)
invalid expression
!12292 = !DIExpression(6, 34, 0, 6)
invalid expression
!17015 = !DIExpression(6, 34, 8, 6)
invalid expression
!30180 = !DIExpression(6, 34, 8)
rustc: /home/dvc/repos/riscv-rust/llvm/lib/IR/Verifier.cpp:4681: virtual bool {anonymous}::VerifierLegacyPass::doFinalization(llvm::Module&): Assertion `!V->hasBrokenDebugInfo() && "Module contains invalid debug info"' failed.
error: Could not compile `core`.

Caused by:
  process didn't exit successfully: `/home/dvc/repos/riscv-rust/rust/build/bootstrap/debug/rustc --crate-name core src/libcore/lib.rs --error-format json --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on -C metadata=776197056af321fd -C extra-filename=-776197056af321fd --out-dir /home/dvc/repos/riscv-rust/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps --target x86_64-unknown-linux-gnu -L dependency=/home/dvc/repos/riscv-rust/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/debug/deps -L dependency=/home/dvc/repos/riscv-rust/rust/build/x86_64-unknown-linux-gnu/stage1-std/debug/deps` (signal: 6, SIGABRT: process abort signal)
thread 'main' panicked at 'command did not execute successfully: "/home/dvc/repos/riscv-rust/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "-j" "4" "--target" "x86_64-unknown-linux-gnu" "--features" "panic-unwind debug-jemalloc jemalloc backtrace" "--manifest-path" "/home/dvc/repos/riscv-rust/rust/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101', src/bootstrap/compile.rs:852:8

[TimNN]

@dvc94ch: This is very likely the debug info issue discussed above. Commenting these lines should "fix" the assertion.

[arielb1]

The #37945 failure should be fixed by https://github.com/llvm-mirror/llvm/commit/7d99ae532b4919d625248fe2b106eed38770c56e, if we choose to apply it.

[alexcrichton]

Awesome, thanks @arielb1! I've rebase our LLVM branch and cherry-picked that change onto it.

[bstrie]

LLVM 5.0 has been released as of yesterday, is there an update to this bug for those following along at home?

[alexcrichton]

No, the status at the top is still the status.

[dylanmckay]

I have kicked off the emscripten upgrade

• Emscripten tracking issue
  
  
  
  • kripken/emscripten-fastcomp#193
  
  
• Pull requests
  
  
  
  • kripken/emscripten-fastcomp#199
  
  
  • kripken/emscripten-fastcomp-clang#19
  
  

Depending on the amount of breakage, I may not have the time to put too much work into fixing the tests in the next week or two. If work goes stale, or even if anybody just feels like it, feel free to help out

Also, any code reviews are definitely welcome!

[ishitatsuyuki]

Just by the way, this will block Arch from pushing any updated Rust compiler as llvm-5.0.0-1 is already in stable repository.

If possible, I would like to see a WIP PR so I can start building dev (easily) with system LLVM.

[cuviper]

FWIW the current beta does build with LLVM 5, just with those debuginfo
issues. It otherwise seemed fine when I tried it, so maybe Arch can just
move up anyway.

[ishitatsuyuki]

I see, #44421 is the blocking issue instead then. Maybe we can cherry pick the fix?

[sajattack]

I am also unable to build due to #44421

[ishitatsuyuki]

@cuviper I have experienced failure with current nightly, even after glibc downgrade.

cargo:warning=../rustllvm/PassWrapper.cpp:29:10: fatal error: llvm/Object/ModuleSummaryIndexObjectFile.h: No such file or directory
cargo:warning= #include "llvm/Object/ModuleSummaryIndexObjectFile.h"  
cargo:warning=          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cargo:warning=compilation terminated.

[ishitatsuyuki]

@alexcrichton can you backport https://github.com/alexcrichton/rust/commit/8687fa0e02061dd8d46ce805afaa75a2a93c1835? I guess it's the only blocker.

[main--]

On Arch Linux with stable Rust+LLVM right now:

$ cargo build
   Compiling fallible-iterator v0.1.3
   Compiling byteorder v1.1.0
   Compiling odds v0.2.25
invalid expression
!2579 = !DIExpression(6, 34, 0, 6)
invalid expression
!2582 = !DIExpression(6, 34, 8, 6)
   Compiling nodrop v0.1.9
   Compiling arrayvec v0.3.23

Edit: Also, debug info is a mess (majorly broken), I downgraded.

[hussamT]

Archlinux's rust doesn't actually depend on llvm-libs. it links statically against llvm.
You can downgrade to llvm4/llvm-libs4, recompile rust using llvm4 (edit out llvm-libs dependency from rust PKGBUILD) and then upgrade back to llvm5.

[ishitatsuyuki]

As we're running behind schedule, is it feasible to backport the compiler-rt matters first? It should fix much build/runtime issues on Arch, AFAIK:

• glibc compat
• ASan linkage

If you have no time to do that, I'm willing to open two PRs.

[martell]

@TIMNN the fix for debug-infogdb was merged into the 5.0 branch as https://reviews.llvm.org/rL309767
Seems like for this release we should skip 5.0.0 and go straight to 5.0.1.
It should be out very shortly.

asm.js seems to be the blocker here.
The real pain point is that asm.js has to do a full upgrade similar to what has to be done for rust.
This doubles the work load for a rust llvm upgrade.
@alexcrichton With asm.js giving birth to wasm and now that LLD has initial wasm linker support hopefully by 6.0.0 we begin a discussion around dropping asm.js if wasm support is where it needs to be? I'm not sure on the browser requirement implications but I thought I should bring this up.

[shepmaster]

begin a discussion around dropping asm.js

I believe you are looking for #44006

[alexcrichton]

Given this problem and the amount of time it's been here, we've concluded that the best way forward here is mostly likely to just ship multiple LLVM backends. I've opened an issue for this and would love some help implementing it! If you're interested in doing so, please just let me know.

[devurandom]

(@ishitatsuyuki commented on Oct 13 )

@alexcrichton can you backport alexcrichton/rust@8687fa0? I guess it's the only blocker.

Where does alexcrichton/rust@8687fa0e02061dd8d46ce805afaa75a2a93c1835 live? It does not seem to be published by any branch.

[ishitatsuyuki]

It's probably superseded with a force push, and anyway I have backported and got it merged into master.

[cuviper]

What's the status of the "invalid expression" DIExpression errors? Has anyone attempted the fix that @eddyb described in https://github.com/rust-lang/rust/issues/43370#issuecomment-317111044?

[alexcrichton]

@cuviper AFAIK no progress has been made

[cuviper]

I filed #47464 specifically for the DIExpression issue.

[cuviper]

47610 should fix DIExpression.

I've added #47611 for a different debuginfo issue.

[alexcrichton]

Awesome, thanks so much for tracking that down @cuviper!

[devurandom]

This will first appear in Rust 1.25, correct?

[cuviper]

It will actually be LLVM 6, but yes, starting in 1.25.

[gaming-hacker]

What's the status on implementing fixes for llvm-6.0?

[martell]

@gaming-hacker llvm 6.0 support was already shipped in 1.25.

[gaming-hacker]

@martell, thanks my bad. there was a nagging bug in Macports i was trying to nail down.