Skip to content

/rust

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debuginfo generation is broken with LLVM 3.8 #36774

Closed
nagisa opened this Issue Sep 27, 2016 · 43 comments

Comments

Assignees

@michaelwoerister michaelwoerister

Labels
A-debuginfo A-mir I-crash P-high T-compiler regression-from-stable-to-beta
Projects
None yet
Milestone
No milestone
10 participants
@nagisa @cuviper @akien-mga @nikomatsakis @sanxiyn @brson @michaelwoerister @eddyb @bluss @rust-highfive
@nagisa
Copy link
Contributor

nagisa commented Sep 27, 2016 •
edited

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.

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

@sanxiyn sanxiyn added the A-debuginfo label Sep 28, 2016

@nagisa

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nagisa commented Sep 28, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 2, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 2, 2016

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

This comment has been minimized.

Sign in to view
Copy link

akien-mga commented Oct 3, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 4, 2016

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

@cuviper cuviper referenced this issue Oct 4, 2016

Closed

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

@nikomatsakis nikomatsakis added regression-from-stable-to-beta A-mir labels Oct 4, 2016

@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Oct 4, 2016

Tagging as regression. cc @rust-lang/compiler
@sanxiyn

This comment has been minimized.

Sign in to view
Copy link
Member

sanxiyn commented Oct 6, 2016

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

@brson brson added T-compiler I-crash labels Oct 6, 2016

@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Oct 6, 2016

Thanks for bisecting @sanxiyn

@brson brson added the I-nominated label Oct 6, 2016

@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Oct 6, 2016

Compiler team please triage.
@nagisa

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nagisa commented Oct 6, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Oct 6, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 6, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Oct 6, 2016

triage: P-high

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

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

@nikomatsakis nikomatsakis assigned michaelwoerister Oct 6, 2016

@sanxiyn

This comment has been minimized.

Sign in to view
Copy link
Member

sanxiyn commented Oct 7, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 7, 2016 •
edited

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 10, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 10, 2016

I'm gonna give rustc 1.11 a try.
@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Oct 12, 2016

@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

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 12, 2016 •
edited

@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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Oct 12, 2016 •
edited

@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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 12, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 13, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 13, 2016

See also: #35547

@cuviper cuviper referenced this issue Oct 13, 2016

Closed

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

@michaelwoerister michaelwoerister referenced this issue Oct 13, 2016

Merged

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

@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 14, 2016

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.

bors added a commit that referenced this issue Oct 16, 2016

@bors
Auto merge of #37153 - michaelwoerister:spread-arg-debuginfo, r=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
dcb6fbe

bors added a commit that referenced this issue Oct 16, 2016

@bors
Auto merge of #37153 - michaelwoerister:spread-arg-debuginfo, r=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
c3216d7

bors added a commit that referenced this issue Oct 17, 2016

@bors
Auto merge of #37153 - michaelwoerister:spread-arg-debuginfo, r=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
da7f8c5
@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Oct 20, 2016

Thanks @michaelwoerister!

Waiting on backport.
@cuviper

This comment has been minimized.

Sign in to view
Copy link
Member

cuviper commented Oct 20, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 21, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

bluss commented Oct 25, 2016 •
edited

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Oct 25, 2016

@bluss :(
@nagisa

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nagisa commented Oct 27, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

bluss commented Oct 27, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Nov 3, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nagisa commented Nov 3, 2016

@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

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Nov 7, 2016

@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.

@michaelwoerister michaelwoerister closed this Nov 7, 2016

@bluss

This comment has been minimized.

Sign in to view
Copy link
Contributor

bluss commented Nov 7, 2016

New issue is #37633
@michaelwoerister

This comment has been minimized.

Sign in to view
Copy link
Contributor

michaelwoerister commented Nov 7, 2016

Thank you, @bluss!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.