Debuginfo generation is broken with LLVM 3.8 #36774

nagisa · 2016-09-27T17:45:32Z

Compiling librustc_mir with optimisations on and debuginfo enabled fails with LLVM assertion:

piece is larger than or outside of variable
  call void @llvm.dbg.declare(metadata %"13.rustc::mir::visit::LvalueContext"* %arg1.sroa.2, metadata !24020, metadata !43416), !dbg !46046
!24020 = !DILocalVariable(arg: 4, scope: !24006, file: !1194, line: 1, type: !"{struct rustc/599ae68a7dffd6c9bf8d7a7e26afb91619ab5f582f32707f1893ef9e2fd1fdbd/94b2}")
!43416 = !DIExpression(DW_OP_bit_piece, 64, 192)
piece is larger than or outside of variable
  call void @llvm.dbg.declare(metadata %"13.rustc::mir::repr::Location"* %arg1.sroa.3, metadata !24020, metadata !46047), !dbg !46046
!24020 = !DILocalVariable(arg: 4, scope: !24006, file: !1194, line: 1, type: !"{struct rustc/599ae68a7dffd6c9bf8d7a7e26afb91619ab5f582f32707f1893ef9e2fd1fdbd/94b2}")
!46047 = !DIExpression(DW_OP_bit_piece, 256, 128)
LLVM ERROR: Broken module found, compilation aborted!

The failure started happening sometime in the past month. Any change related to how we generate debuginfo for variables is a suspect as it likely specifies the size of the variable incorrectly (as per https://llvm.org/bugs/show_bug.cgi?id=23712)

Works fine with LLVM bundled with rust.

The text was updated successfully, but these errors were encountered:

nagisa · 2016-09-28T15:23:31Z

This is a regression-from-stable-to-nightly (-beta in a few days) and and I-ICE.

cuviper · 2016-10-02T00:23:26Z

I'm not sure which stable you meant, but I'm seeing this regression on stable 1.12 while building git2 for cargo, while compiling the same with 1.11 is fine. Here's the excerpt from Fedora's full build.log:

piece covers entire variable
  call void @llvm.dbg.value(metadata i64 %1, i64 0, metadata !10414, metadata !31684), !dbg !34307
!10414 = !DILocalVariable(arg: 3, scope: !10403, file: !10404, line: 1977, type: !"{struct git2/bd2b4ed1a06da7fa58e6c6d8f6516e398bfeede5c10924aaad59e63a932b47a7/b9f}")
!31684 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.value(metadata i64 %2, i64 0, metadata !10414, metadata !31685), !dbg !34307
!10414 = !DILocalVariable(arg: 3, scope: !10403, file: !10404, line: 1977, type: !"{struct git2/bd2b4ed1a06da7fa58e6c6d8f6516e398bfeede5c10924aaad59e63a932b47a7/b9f}")
!31685 = !DIExpression(DW_OP_bit_piece, 64, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.declare(metadata %"2.std::option::Option<diff::DiffHunk>"* %arg1.sroa.2, metadata !10429, metadata !34312), !dbg !34313
!10429 = !DILocalVariable(arg: 4, scope: !10418, file: !10404, line: 1977, type: !"{struct git2/bd2b4ed1a06da7fa58e6c6d8f6516e398bfeede5c10924aaad59e63a932b47a7/b9b}")
!34312 = !DIExpression(DW_OP_bit_piece, 64, 128)
piece covers entire variable
  call void @llvm.dbg.value(metadata i64 %1, i64 0, metadata !10429, metadata !31684), !dbg !34313
!10429 = !DILocalVariable(arg: 4, scope: !10418, file: !10404, line: 1977, type: !"{struct git2/bd2b4ed1a06da7fa58e6c6d8f6516e398bfeede5c10924aaad59e63a932b47a7/b9b}")
!31684 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.value(metadata i64 %3, i64 0, metadata !10429, metadata !34315), !dbg !34313
!10429 = !DILocalVariable(arg: 4, scope: !10418, file: !10404, line: 1977, type: !"{struct git2/bd2b4ed1a06da7fa58e6c6d8f6516e398bfeede5c10924aaad59e63a932b47a7/b9b}")
!34315 = !DIExpression(DW_OP_bit_piece, 192, 64)
piece covers entire variable
  call void @llvm.dbg.value(metadata i64 %1, i64 0, metadata !10443, metadata !31684), !dbg !34318
!10443 = !DILocalVariable(arg: 3, scope: !10433, file: !10404, line: 1977, type: !"{struct git2/bd2b4ed1a06da7fa58e6c6d8f6516e398bfeede5c10924aaad59e63a932b47a7/ba5}")
!31684 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.value(metadata i64 %2, i64 0, metadata !10443, metadata !31685), !dbg !34318
!10443 = !DILocalVariable(arg: 3, scope: !10433, file: !10404, line: 1977, type: !"{struct git2/bd2b4ed1a06da7fa58e6c6d8f6516e398bfeede5c10924aaad59e63a932b47a7/ba5}")
!31685 = !DIExpression(DW_OP_bit_piece, 64, 64)
LLVM ERROR: Broken module found, compilation aborted!
Build failed, waiting for other jobs to finish...
error: Could not compile `git2`.
Caused by:
  Process didn't exit successfully: `rustc .cargo/registry/src/-059c64927a508553/git2-0.4.4/src/lib.rs --crate-name git2 --crate-type lib -C opt-level=3 --cfg feature="default" --cfg feature="https" --cfg feature="ssh" --cfg feature="libgit2-sys" -C metadata=6ff6b7061c01db01 -C extra-filename=-6ff6b7061c01db01 --out-dir /builddir/build/BUILD/cargo-0.13.0/target/x86_64-unknown-linux-gnu/release/deps --emit=dep-info,link --target x86_64-unknown-linux-gnu -L dependency=/builddir/build/BUILD/cargo-0.13.0/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/builddir/build/BUILD/cargo-0.13.0/target/x86_64-unknown-linux-gnu/release/deps --extern url=/builddir/build/BUILD/cargo-0.13.0/target/x86_64-unknown-linux-gnu/release/deps/liburl-bf7ff6dce96f3de6.rlib --extern libc=/builddir/build/BUILD/cargo-0.13.0/target/x86_64-unknown-linux-gnu/release/deps/liblibc-d7f563bb6cbdc70a.rlib --extern bitflags=/builddir/build/BUILD/cargo-0.13.0/target/x86_64-unknown-linux-gnu/release/deps/libbitflags-877983b26a517965.rlib --extern libgit2_sys=/builddir/build/BUILD/cargo-0.13.0/target/x86_64-unknown-linux-gnu/release/deps/liblibgit2_sys-c6ac804eabc4dcd5.rlib --cap-lints allow -L native=/usr/lib64 -L native=/usr/lib64 -L native=/usr/lib64 -L native=/usr/lib64 -C opt-level=3 -g` (exit code: 1)

cuviper · 2016-10-02T19:42:02Z

I can also reproduce this compiling git2 with Rust 1.11 and RUSTFLAGS='-C opt-level=3 -g -Zorbit', using Fedora's same LLVM 3.8 in all cases. Even just opt-level=1 still fails, but 0 is ok.

akien-mga · 2016-10-03T08:13:19Z

I can confirm the error reported by @cuviper on Mageia too, using Rust 1.12.0 and LLVM 3.8.1, on both x86_64 and i586. The rust and cargo packaging in Mageia are otherwise synced with Fedora. Full build log on x86_64.

cuviper · 2016-10-04T06:39:36Z

I also just confirmed that 1.12 with -Zorbit=no builds fine, so it definitely looks like a MIR issue.

nikomatsakis · 2016-10-04T12:53:35Z

Tagging as regression. cc @rust-lang/compiler

sanxiyn · 2016-10-06T08:38:54Z

Bisecting from LLVM 3.8 to LLVM 3.9 led to r267296. That is, r267295 errors, and r267296 does not.

brson · 2016-10-06T16:56:08Z

Thanks for bisecting @sanxiyn

brson · 2016-10-06T16:58:03Z

Compiler team please triage.

nagisa · 2016-10-06T17:01:50Z

Backporting an LLVM patch is not an option, as we do not control that LLVM 3.8 which distributions use. Seems to me like there’s exactly two viable fixes:

A conditional wrapper in rustllvm which uses the 3.8 behaviour on 3.8/3.7;
Require LLVM 3.9 :)

nikomatsakis · 2016-10-06T17:03:13Z

Do we know what we would have to do in order to be "3.8-compatible"?

cuviper · 2016-10-06T18:05:13Z

FWIW, I've been asked many times if Fedora will keep up to date with the latest Rust, presumably by people who really want that. If we suddenly require LLVM 3.9, this is a serious roadblock to upgrades. Even Fedora Rawhide has not updated LLVM yet!

A backported LLVM patch is possible -- if we know it fixes the problem, I can ask our LLVM maintainers to apply it. However, if I'm not mistaken that patch is modifying a couple public headers, which is bad for API compatibility and probably signals ABI changes too. A backport would have to mitigate that.

If it's possible for rustc/rustllvm/whatever to make a change for 3.8-compatibility, I'd be much happier backporting that to our rust package.

nikomatsakis · 2016-10-06T20:43:15Z

triage: P-high

assigning to @michaelwoerister to investigate a bit more what is happening here.

sanxiyn · 2016-10-07T11:49:12Z

Reduced test case to 60 lines: https://gist.github.com/sanxiyn/b1d666f132d3314cd999bb9b629acc2b

michaelwoerister · 2016-10-07T20:47:45Z

@sanxiyn Thank you so much for the reduction! That will be very helpful.

michaelwoerister · 2016-10-10T20:46:44Z

So, I've been able to reproduce this (thanks again, @sanxiyn) but I cannot find any real difference in the debuginfo produced by the working and by the failing versions of LLVM. Type sizes and alignments and field offsets seem to be correct, and they are the same in both versions.
Is there a version of rustc that still worked with LLVM 3.8? That is, are we sure this ever worked? Debuginfo+Optimization is being tested on the buildbots only since recently, right?

michaelwoerister · 2016-10-10T20:50:31Z

I'm gonna give rustc 1.11 a try.

michaelwoerister · 2016-10-12T20:49:41Z

Alright, bisecting Rust between 1.11 and 1.12 has revealed that PR #35197 somehow breaks LLVM 3.8. I don't have a clue as to why that is. Any idea, @eddyb?

For reference: I bisected by building Rust against LLVM 3.8.0 and checking whether it could build Cargo with debuginfo+optimizations (Cargo is the project for which building fails in the logs provided above by @cuviper).

eddyb · 2016-10-12T21:00:00Z

@michaelwoerister For the record, that PR is where MIR trans was turned on. So you'll want to go back further and add -Zorbit, except some trans changes prevented it from having the full effect it should have, in an undetermined range of commits (which that PR fixes) 😞.

cuviper · 2016-10-12T21:00:08Z

@michaelwoerister I'm a little confused, because even base 1.11 fails for me when using -Zorbit, and 1.12 is fine for me with -Zorbit=no. Did you use MIR the whole time you were bisecting?
(OK, that makes more sense with @eddyb's comment, if MIR was turned on there.)

michaelwoerister · 2016-10-12T21:06:43Z

I thought mir-trans was already enabled in #34096? That PR still passes just fine.

eddyb · 2016-10-12T21:25:35Z

@michaelwoerister #34096 has absolutely no effect for cross-crate MIR because someone broke it.

michaelwoerister · 2016-10-12T21:28:11Z

@eddyb Can you elaborate? Do you mean that inlined functions were still translated with old-trans by default?

eddyb · 2016-10-12T21:30:59Z

@michaelwoerister Not just by default, the compiler simply couldn't inline MIR cross-crate because the DefIds were wrong (they were the inlined AST DefIds instead of the original ones).

michaelwoerister · 2016-10-12T21:32:53Z

@eddyb So translation fell back to old-trans when it didn't find the MIR in the extern crate?

eddyb · 2016-10-12T21:36:27Z

@michaelwoerister Right, it never found the MIR cross-crate so it used old trans (like -Zorbit=off).

michaelwoerister · 2016-10-12T21:48:18Z

So, it's possible that neither MIR-trans nor old-trans never actually worked reliably with LLVM 3.8 with debuginfo+optimizations enabled and MIR-trans is just more likely to run into this bug, right? At least I have no indication so far, that MIR trans generates different or faulty debuginfo. It might just generate code that is more amenable to SROA or something.

cuviper · 2016-10-12T22:02:40Z

I can't comment on likelihood, but anecdotally I've never seen this issue without MIR.

I just tried even older rustc -Zorbit building cargo 0.13. Even 1.10.0 fails similarly on git2:

piece covers entire variable
  call void @llvm.dbg.value(metadata i64 %1, i64 0, metadata !17951, metadata !31648), !dbg !37787
!17951 = !DILocalVariable(arg: 3, scope: !17940, file: !10283, line: 1987, type: !"{struct git2/5d1ef9158b6e807755484050a668f7de0ad4666add46b252de68fc8c4e54b3e1/bb7}")
!31648 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.value(metadata i64 %2, i64 0, metadata !17951, metadata !31649), !dbg !37787
!17951 = !DILocalVariable(arg: 3, scope: !17940, file: !10283, line: 1987, type: !"{struct git2/5d1ef9158b6e807755484050a668f7de0ad4666add46b252de68fc8c4e54b3e1/bb7}")
!31649 = !DIExpression(DW_OP_bit_piece, 64, 64)
piece covers entire variable
  call void @llvm.dbg.value(metadata i64 %1, i64 0, metadata !18006, metadata !31648), !dbg !37803
!18006 = !DILocalVariable(arg: 3, scope: !17997, file: !10283, line: 1987, type: !"{struct git2/5d1ef9158b6e807755484050a668f7de0ad4666add46b252de68fc8c4e54b3e1/bb1}")
!31648 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.value(metadata i64 %2, i64 0, metadata !18006, metadata !31649), !dbg !37803
!18006 = !DILocalVariable(arg: 3, scope: !17997, file: !10283, line: 1987, type: !"{struct git2/5d1ef9158b6e807755484050a668f7de0ad4666add46b252de68fc8c4e54b3e1/bb1}")
!31649 = !DIExpression(DW_OP_bit_piece, 64, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.declare(metadata %"2.std::option::Option<diff::DiffHunk<'static>>"* %arg1.sroa.2, metadata !18065, metadata !37817), !dbg !37818
!18065 = !DILocalVariable(arg: 4, scope: !18055, file: !10283, line: 1987, type: !"{struct git2/5d1ef9158b6e807755484050a668f7de0ad4666add46b252de68fc8c4e54b3e1/bad}")
!37817 = !DIExpression(DW_OP_bit_piece, 64, 128)
piece covers entire variable
  call void @llvm.dbg.value(metadata i64 %1, i64 0, metadata !18065, metadata !31648), !dbg !37818
!18065 = !DILocalVariable(arg: 4, scope: !18055, file: !10283, line: 1987, type: !"{struct git2/5d1ef9158b6e807755484050a668f7de0ad4666add46b252de68fc8c4e54b3e1/bad}")
!31648 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  call void @llvm.dbg.value(metadata i64 %3, i64 0, metadata !18065, metadata !37820), !dbg !37818
!18065 = !DILocalVariable(arg: 4, scope: !18055, file: !10283, line: 1987, type: !"{struct git2/5d1ef9158b6e807755484050a668f7de0ad4666add46b252de68fc8c4e54b3e1/bad}")
!37820 = !DIExpression(DW_OP_bit_piece, 192, 64)
LLVM ERROR: Broken module found, compilation aborted!
error: Could not compile `git2`.

Whereas 1.9.0 finally fails differently and ICEs on git2:

error: internal compiler error: ../src/librustc_trans/mir/operand.rs:127: use of tmp24 before def
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'Box<Any>', ../src/libsyntax/errors/mod.rs:575

1.9 also errors on rustc-serialize:

!dbg attachment points at wrong subprogram for function
!5658 = distinct !DISubprogram(name: "read_f64", linkageName: "_ZN15rustc_serialize4json8{{impl}}8read_f64E", scope: !3127, file: !3126, line: 2109, type: !5659, isLocal: false, isDefinition: true, scopeLine: 2109, flags: DIFlagPrototyped, isOptimized: true, templateParams: !246, variables: !246)
void (%"2.std::result::Result<f64, json::DecoderError>"*, %"json::Decoder"*)* @"_ZN52_$LT$json..Decoder$u20$as$u20$serialize..Decoder$GT$8read_f6417hcbf09878ab2be073E"
  tail call void @llvm.dbg.value(metadata i64 %145, i64 0, metadata !5769, metadata !8453), !dbg !8454
!8454 = !DILocation(line: 1054, scope: !5765)
!5765 = distinct !DISubprogram(name: "abs", linkageName: "_ZN15rustc_serialize3num8{{impl}}3absE", scope: !2633, file: !2632, line: 1054, type: !5766, isLocal: true, isDefinition: true, scopeLine: 1054, flags: DIFlagPrototyped, isOptimized: true, templateParams: !246, variables: !5768)
!5765 = distinct !DISubprogram(name: "abs", linkageName: "_ZN15rustc_serialize3num8{{impl}}3absE", scope: !2633, file: !2632, line: 1054, type: !5766, isLocal: true, isDefinition: true, scopeLine: 1054, flags: DIFlagPrototyped, isOptimized: true, templateParams: !246, variables: !5768)
LLVM ERROR: Broken function found, compilation aborted!

cuviper · 2016-10-13T01:40:53Z

Hmm, external LLVM may be a red herring. I just tried with nightly and got a similar error, though it came from a different place.

$ rustc -Vv
rustc 1.14.0-nightly (a3bc191b5 2016-10-10)
binary: rustc
commit-hash: a3bc191b5f41df5143cc65084b13999896411817
commit-date: 2016-10-10
host: x86_64-unknown-linux-gnu
release: 1.14.0-nightly
$ cargo -Vv
cargo 0.13.0-nightly (957a47b 2016-10-10)
$ git rev-parse HEAD
ee3acca1035f41d87a6be91b42daf02c565ae996
$ RUSTFLAGS=-g cargo build --release
[...]
   Compiling cargo v0.14.0 (file:///home/jistone/rust/cargo)
piece is larger than or outside of variable
  tail call void @llvm.dbg.value(metadata i8* %2, i64 0, metadata !46311, metadata !2682), !dbg !46315
!46311 = !DILocalVariable(arg: 4, scope: !46265, file: !10, line: 1, type: !46295)
!2682 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  tail call void @llvm.dbg.value(metadata i64 %3, i64 0, metadata !46311, metadata !2679), !dbg !46315
!46311 = !DILocalVariable(arg: 4, scope: !46265, file: !10, line: 1, type: !46295)
!2679 = !DIExpression(DW_OP_bit_piece, 64, 64)
piece is larger than or outside of variable
  tail call void @llvm.dbg.value(metadata i32 %5, i64 0, metadata !46311, metadata !46317), !dbg !46315
!46311 = !DILocalVariable(arg: 4, scope: !46265, file: !10, line: 1, type: !46295)
!46317 = !DIExpression(DW_OP_bit_piece, 256, 32)
LLVM ERROR: Broken function found, compilation aborted!
error: Could not compile `cargo`.

michaelwoerister · 2016-10-13T13:37:56Z

See also: #35547

michaelwoerister · 2016-10-14T19:28:47Z

Update: #37153 should help with at least some of these cases, maybe all. I've also filed a bug report with LLVM: https://llvm.org/bugs/show_bug.cgi?id=30703

Also note, that if you don't need full debuginfo, just line tables for profiling and backtraces, then compiling with "-Cdebuginfo=1" is sufficient and will prevent these assertions from being triggered.

@eddyb

debuginfo: Handle spread_arg case in MIR-trans in a more stable way. Use `VariableAccess::DirectVariable` instead of `VariableAccess::IndirectVariable` in order not to make LLVM's SROA angry. This is a step towards fixing #36774 and #35547. At least, I can build Cargo with optimizations + debuginfo again. r? @eddyb

@eddyb

debuginfo: Handle spread_arg case in MIR-trans in a more stable way. Use `VariableAccess::DirectVariable` instead of `VariableAccess::IndirectVariable` in order not to make LLVM's SROA angry. This is a step towards fixing #36774 and #35547. At least, I can build Cargo with optimizations + debuginfo again. r? @eddyb

brson · 2016-10-20T16:30:57Z

Thanks @michaelwoerister!

Waiting on backport.

cuviper · 2016-10-20T23:51:45Z

Aren't those backports done already? beta #37256 and stable #37173.

michaelwoerister · 2016-10-21T00:00:02Z

Yes, I thought so too. The code in the two PRs looks correct.

bluss · 2016-10-25T13:17:37Z

PR #37315 seems to run into something like this, after the partial fix. (Note: It was triggered by the flat_map part linked here, the PR was since updated to remove it):

piece is larger than or outside of variable
  tail call void @llvm.dbg.value(metadata %"ty::FieldDefData"* %2, i64 0, metadata !105417, metadata !6823), !dbg !105421
!105417 = !DILocalVariable(arg: 3, scope: !105386, file: !15, line: 1, type: !105406)
!6823 = !DIExpression(DW_OP_bit_piece, 64, 64)
LLVM ERROR: Broken function found, compilation aborted!

The line inside librustc that produced the assertion was here, where .fold() is called on something using both .flat_map() and .map().

michaelwoerister · 2016-10-25T13:42:47Z

@bluss :(

nagisa · 2016-10-27T20:29:39Z

The issue reported by @bluss in the comment above seems to happen on our in-tree LLVM (our buildbots). Would be good to try minimise the reproduction and see if it also happens on external LLVM first.

bluss · 2016-10-27T20:35:13Z

@nagisa I didn't even know where to begin minimizing it, since it was triggered by code in librustc, a pretty large crate.

nikomatsakis · 2016-11-03T16:18:35Z

Does that suggest that the issue reported by @bluss is a separate issue?

nagisa · 2016-11-03T16:53:48Z

@nikomatsakis That seems about right. I also feel that the issue reported by @bluss might not be just a regression, but a genuine bug. Either way, a good idea would be to fill a new issue and try to reproduce what @bluss saw.

Other than that I can confirm that bootstrapping rustc with LLVM 3.8 does not ICE anymore, so we’re good in that regard.

michaelwoerister · 2016-11-07T19:09:51Z

@bluss Would you mind opening a new issue for the problem you discovered? You can copy your comment from above, that is informative enough.

Closing this issue since the original problem has been solved.

bluss · 2016-11-07T19:16:16Z

New issue is #37633

michaelwoerister · 2016-11-07T19:22:33Z

Thank you, @bluss!

nagisa changed the title ~~Debuginfo generation is broken in LLVM 3.8~~ Debuginfo generation is broken with LLVM 3.8 Sep 27, 2016

sanxiyn added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Sep 28, 2016

cuviper mentioned this issue Oct 4, 2016

1.12.0: High memory usage when linking in release mode with debug info #36926

Closed

nikomatsakis added regression-from-stable-to-beta Performance or correctness regression from stable to beta. A-MIR Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html labels Oct 4, 2016

brson added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. labels Oct 6, 2016

brson added the I-nominated label Oct 6, 2016

rust-highfive added P-high High priority and removed I-nominated labels Oct 6, 2016

nikomatsakis assigned michaelwoerister Oct 6, 2016

cuviper mentioned this issue Oct 13, 2016

LLVM error and build failure: "piece covers entire variable" #35547

Closed

michaelwoerister mentioned this issue Oct 13, 2016

debuginfo: Handle spread_arg case in MIR-trans in a more stable way. #37153

Merged

michaelwoerister closed this as completed Nov 7, 2016

Debuginfo generation is broken with LLVM 3.8 #36774

Debuginfo generation is broken with LLVM 3.8 #36774

Comments

nagisa commented Sep 27, 2016 • edited Loading

nagisa commented Sep 28, 2016

cuviper commented Oct 2, 2016

cuviper commented Oct 2, 2016

akien-mga commented Oct 3, 2016

cuviper commented Oct 4, 2016

nikomatsakis commented Oct 4, 2016

sanxiyn commented Oct 6, 2016

brson commented Oct 6, 2016

brson commented Oct 6, 2016

nagisa commented Oct 6, 2016

nikomatsakis commented Oct 6, 2016

cuviper commented Oct 6, 2016

nikomatsakis commented Oct 6, 2016

sanxiyn commented Oct 7, 2016

michaelwoerister commented Oct 7, 2016 • edited Loading

michaelwoerister commented Oct 10, 2016

michaelwoerister commented Oct 10, 2016

michaelwoerister commented Oct 12, 2016

eddyb commented Oct 12, 2016

cuviper commented Oct 12, 2016 • edited Loading

michaelwoerister commented Oct 12, 2016

eddyb commented Oct 12, 2016

michaelwoerister commented Oct 12, 2016

eddyb commented Oct 12, 2016 • edited Loading

michaelwoerister commented Oct 12, 2016

eddyb commented Oct 12, 2016

michaelwoerister commented Oct 12, 2016

cuviper commented Oct 12, 2016

cuviper commented Oct 13, 2016

michaelwoerister commented Oct 13, 2016

michaelwoerister commented Oct 14, 2016

brson commented Oct 20, 2016

cuviper commented Oct 20, 2016

michaelwoerister commented Oct 21, 2016

bluss commented Oct 25, 2016 • edited Loading

michaelwoerister commented Oct 25, 2016

nagisa commented Oct 27, 2016

bluss commented Oct 27, 2016

nikomatsakis commented Nov 3, 2016

nagisa commented Nov 3, 2016

michaelwoerister commented Nov 7, 2016

bluss commented Nov 7, 2016

michaelwoerister commented Nov 7, 2016

nagisa commented Sep 27, 2016 •

edited

Loading

michaelwoerister commented Oct 7, 2016 •

edited

Loading

cuviper commented Oct 12, 2016 •

edited

Loading

eddyb commented Oct 12, 2016 •

edited

Loading

bluss commented Oct 25, 2016 •

edited

Loading