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

[bfops]

This aggressive build failure happens consistently if you try to build rust-clippy with opt-level=1 set. Here's a fork that does it out of the box: https://github.com/bfops/rust-clippy.git.

piece covers entire variable
  tail call void @llvm.dbg.value(metadata %"17.rustc::hir::Expr"** %1, i64 0, metadata !70093, metadata !8774), !dbg !70097
!70093 = !DILocalVariable(arg: 3, scope: !70077, file: !41572, line: 1948, type: !9419)
!8774 = !DIExpression(DW_OP_bit_piece, 0, 64)
piece is larger than or outside of variable
  tail call void @llvm.dbg.value(metadata %"17.rustc::hir::Expr"** %2, i64 0, metadata !70093, metadata !8776), !dbg !70097
!70093 = !DILocalVariable(arg: 3, scope: !70077, file: !41572, line: 1948, type: !9419)
!8776 = !DIExpression(DW_OP_bit_piece, 64, 64)
LLVM ERROR: Broken function found, compilation aborted!
error: Could not compile `clippy_lints`.

[thepowersgang]

I've recently encountered this when compiling a program from my OS project (just one out of several userland binaries)

(Compiling https://github.com/thepowersgang/rust_os/blob/master/Usermode/fileviewer/src/main.rs using rustc 1.13.0-nightly (923bac459 2016-09-06))

piece is larger than or outside of variable
  tail call void @llvm.dbg.value(metadata void (i8*)** %3, i64 0, metadata !5538, metadata !5557), !dbg !5554
!5538 = !DILocalVariable(arg: 3, scope: !5539, file: !293, line: 1, type: !2033)
!5557 = !DIExpression(DW_OP_bit_piece, 128, 64)
piece is larger than or outside of variable
  tail call void @llvm.dbg.value(metadata void (i8*)** %3, i64 0, metadata !5538, metadata !5557), !dbg !5567
!5538 = !DILocalVariable(arg: 3, scope: !5539, file: !293, line: 1, type: !2033)
!5557 = !DIExpression(DW_OP_bit_piece, 128, 64)
LLVM ERROR: Broken function found, compilation aborted!

Notably - The function call mentioned does not appear in the file created by --emit llvm-ir

[thepowersgang]

Occurs up with optimisation levels 1, 2, and s but not 0 or 3.

With level 1, only a single call is mentioned, and different optimisation levels change the ! numbers

[thepowersgang]

@bfops - Your branch has bit-rotted against nightly.

[bfops]

Thanks, fixed! Error still happens for me on the updated branch.

[thepowersgang]

I've located the last working nightly - rustc 1.12.0-nightly (a005b6785 2016-08-02) (dated 2016-08-03) compiles both my code and @bfops' fork (bfops/rust-clippy@e63c81c) successfully, but rustc 1.12.0-nightly (0a3180baa 2016-08-03) (dated 2016-08-04) fails to compile both.

Changes between these two revisions: a005b67...0a3180b

[thepowersgang]

From some (very slow) commit bisecting - it looks like ee977e7 is at fault - but I do not know how (and I'm not 100% sure it is that commit)

[thepowersgang]

cc @eddyb - The above commit was by you - can you see a reason for it to cause this error?

[eddyb]

This looks lika a LLVM bug, we don't emit DW_OP_bit_piece ourselves, so LLVM may be optimizing a newtype out of memory into a value but shoot itself in the foot by using DW_OP_bit_piece.

[thepowersgang]

https://llvm.org/bugs/show_bug.cgi?id=23712 - A similar issue on LLVM's tracker - Caused by bad debug information (incorrect size information for a variable)
https://llvm.org/bugs/show_bug.cgi?id=24923 - Also same error message, this time caused by the same root cause (bad size information) but due to two types with the same name.

[thepowersgang]

Thanks to bugpoint - it looks like the culprit function in my case is

_ZN298_$LT$wtk..input..button..BoxCb$LT$$u27$a$C$$u20$T$GT$$u20$as$u20$core..ops..Fn$LT$$LP$$RF$$u27$b1$u20$wtk..input..button..Button$LT$T$C$$u20$wtk..input..button..BoxCb$LT$$u27$a$C$$u20$T$GT$$GT$$C$$u20$$RF$$u27$b2$u20$mut$u20$wtk..window..WindowTrait$LT$$u27$b3$GT$$u20$$u2b$$u20$$u27$b2$RP$$GT$$GT$4call17hc4b025e85098d2b2E

Aka <BoxCb<'a, T> as Fn(&Button<T, BoxCb<T>>, &WindowTrait)>::call - which is a manual implementation of Fn for a container (Source)

  call void @llvm.dbg.declare(metadata { %"11.wtk::Button<wtk::Colour, wtk::input::button::BoxCb<wtk::Colour>>.35.317.599.13"*, { i8*, void (i8*)** } }* %arg1, metadata !424, metadata !425), !dbg !426
!424 = !DILocalVariable(arg: 2, scope: !377, file: !378, line: 26, type: !391)
!425 = !DIExpression(DW_OP_deref, DW_OP_plus, 0)

Is converted into

  call void @llvm.dbg.value(metadata %"11.wtk::Button<wtk::Colour, wtk::input::button::BoxCb<wtk::Colour>>.35.317.599.13"* %1, i64 0, metadata !17, metadata !22), !dbg !23
!17 = !DILocalVariable(arg: 2, scope: !4, file: !5, line: 26, type: !18)
!22 = !DIExpression(DW_OP_bit_piece, 0, 64)

I can't see anything directly here that fits the two bugs I mentioned above, but I'm not proficient in LLVM IR.

[thepowersgang]

Strike that last note:

%arg1 = alloca { %"11.wtk::Button<wtk::Colour, wtk::input::button::BoxCb<wtk::Colour>>.35.317.599.13"*, { i8*, void (i8*)** } }
...
!391 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "&wtk::input::button::Button<wtk::surface::Colour, wtk::input::button::BoxCb<wtk::surface::Colour>>", baseType: !392, size: 64, align: 64)

The alloca is for two pointers (128 bits), but the debug information associated with the variable is 64 bits long

(Reduced IR thanks to bugpoint at https://gist.github.com/thepowersgang/e9dce3f87dee14575576d08f602bf396 , only difference to broken areas is the debug info numbers)