SIGABRT when compiling with -Z lto and extern mod extra

[japaric]

These three sources 013.rs, 016.rs and 020.rs generate a SIGABRT when using -Z lto:

$ RUST_LOG=1 rustc -Z lto **/013.rs
rustc: /var/tmp/paludis/build/dev-lang-rust-scm/work/rust-scm/src/llvm/lib/Transforms/Utils/ValueMapper.cpp:194: void llvm::RemapInstruction(llvm::Instruction*, llvm::ValueToValueMapTy&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*): Assertion `(Flags & RF_IgnoreMissingEntries) && "Referenced value not in value map!"' failed.
[1]    7320 abort (core dumped)  RUST_LOG=1 rustc -Z lto **/013.rs
RUST_LOG=1 rustc -Z lto **/013.rs  1.57s user 0.16s system 99% cpu 1.729 total
$ echo $?
134

Exit code is 134: 128 + 6 (SIGABRT)

Here is the backtrace:

#0  0x00007ffff3917309 in raise () from /lib64/libc.so.6
#1  0x00007ffff3918648 in abort () from /lib64/libc.so.6
#2  0x00007ffff3910446 in ?? () from /lib64/libc.so.6
#3  0x00007ffff39104f2 in __assert_fail () from /lib64/libc.so.6
#4  0x00007ffff4fef6bf in llvm::RemapInstruction(llvm::Instruction*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*> >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#5  0x00007ffff4f8953c in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#6  0x00007ffff4f8aa3a in llvm::CloneAndPruneFunctionInto(llvm::Function*, llvm::Function const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*> >&, bool, llvm::SmallVectorImpl<llvm::ReturnInst*>&, char const*, llvm::ClonedCodeInfo*, llvm::DataLayout const*, llvm::Instruction*) () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#7  0x00007ffff4f992e9 in llvm::InlineFunction(llvm::CallSite, llvm::InlineFunctionInfo&, bool) () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#8  0x00007ffff4727a80 in llvm::Inliner::runOnSCC(llvm::CallGraphSCC&) () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#9  0x00007ffff4ff716b in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#10 0x00007ffff51e5c03 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#11 0x00007ffff51483be in LLVMRunPassManager () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#12 0x00007ffff4598e6c in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#13 0x00007ffff4599df0 in back::lto::run::hc6055d9aa3db2681au::v0.10.pre () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#14 0x00007ffff459902c in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#15 0x00007ffff433a4ac in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#16 0x00007ffff4597414 in back::link::write::run_passes::ha0e68a6beff0214eaY::v0.10.pre () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#17 0x00007ffff433a4ac in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#18 0x00007ffff460914d in driver::driver::phase_5_run_llvm_passes::h283e8b1387e78abbae::v0.10.pre () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#19 0x00007ffff460c207 in driver::driver::compile_input::hc281accfdef80b3fa7::v0.10.pre () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#20 0x00007ffff4632d32 in run_compiler::h361080d373c4eca6a7::v0.10.pre () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#21 0x00007ffff4641136 in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#22 0x00007ffff463e580 in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#23 0x00007ffff463857e in ?? () from /usr/bin/../lib/librustc-0d83f02f-0.10-pre.so
#24 0x00007ffff740ab18 in ?? () from /usr/bin/../lib/libgreen-80d9e76a-0.10-pre.so
#25 0x00007ffff77599b8 in ?? () from /usr/bin/../lib/libstd-966edb7e-0.10-pre.so
#26 0x00007ffff776170c in rust_try () from /usr/bin/../lib/libstd-966edb7e-0.10-pre.so
#27 0x00007ffff7759921 in rt::task::Task::run::h2470de2b1d72a017Zcag::v0.10.pre () from /usr/bin/../lib/libstd-966edb7e-0.10-pre.so
#28 0x00007ffff740a62f in ?? () from /usr/bin/../lib/libgreen-80d9e76a-0.10-pre.so
#29 0x0000000000000000 in ?? ()

In this repository you can find another 18 rust sources that compile fine with -Z lto.

The difference between the sources, is that the ones that don't work have a extern mod extra directive and use the bigint module. However I have not been able to pinpoint the exact condition that reproduces the problem, for example the following code compiles successfully with -Z lto:

extern mod extra;

use extra::bigint::BigInt;
use std::num::One;

fn main() {
    let a: BigInt = One::one();

    println!("{:?}", a);
}

Extra info:

$ rustc -v
rustc 0.10-pre (b3d10f4 2014-01-28 05:11:28 -0800)
host: x86_64-unknown-linux-gnu

cc @alexcrichton

[alexcrichton]

Just glanced a bit, but thank you for the thorough report! I will investigate this.

[alexcrichton]

These all die in LLVM, and it appears that it's something funky of how we link two LLVM modules together. If I dump the bytecode right before optimizations and then run llc over that, it works just fine. Some internal state of the LLVM module must be going awry...

[japaric]

Triage: problem still present

I can confirm this problem only occurs with the num::bigint module. I have other programs that compile fine with -Z lto and use the extra, num, serialize and time crates.

Minimal example that reproduces the problem:

// foo.rs
extern crate num;

use num::bigint::BigInt;
use std::num::One;

fn main() {
    let a: BigInt = One::one();

    println!("{}", a.to_str());
}

$ rustc -Z lto foo.rs
rustc: /var/tmp/paludis/build/dev-lang-rust-scm/work/rust-scm/src/llvm/lib/Transforms/Utils/ValueMapper.cpp:194: void llvm::RemapInstruction(llvm::Instruction*, llvm::ValueToValueMapTy&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*): Assertion `(Flags & RF_IgnoreMissingEntries) && "Referenced value not in value map!"' failed.
[1]    31382 abort (core dumped)  rustc -Z lto foo.rs

exit code is 134, the backtrace is similar

$ rustc --version
rustc 0.10-pre (33768c4 2014-03-07 02:51:39 -0800)
host: x86_64-unknown-linux-gnu

[japaric]

This issue is gone now, I did a git bisect and found that PR #12924 "fixed" the issue.

Closing.