ICE compiling stage2 libcore, when building with LLVM-3.5

[lucab]

When building with (system-installed) LLVM 3.5, the following assertion is triggered in libstd/hash.
This ICE recently surfaced after PR #21588. However, it looks like somebody already experienced it in #2235.

$ make
cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu
cfg: enabling more debugging (CFG_ENABLE_DEBUG)
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: good valgrind for x86_64-unknown-linux-gnu is 1
cfg: using CC=gcc (CFG_CC)
cfg: enabling valgrind run-pass tests (CFG_ENABLE_VALGRIND_RPASS)
rustc: x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/rustdoc
cp: x86_64-unknown-linux-gnu/stage2/lib/librustdoc
cp: x86_64-unknown-linux-gnu/stage2/bin/rustdoc
rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore
/home/lbruno/src/upstream/rust/src/libcore/lib.rs:67:12: 67:26 warning: feature is deprecated and will only be available for a limited time, please rewrite code that relies on it
/home/lbruno/src/upstream/rust/src/libcore/lib.rs:67 #![feature(old_impl_check)]
                                                                ^~~~~~~~~~~~~~
/home/lbruno/src/upstream/rust/src/libcore/lib.rs:67:12: 67:26 warning: feature is deprecated and will only be available for a limited time, please rewrite code that relies on it
/home/lbruno/src/upstream/rust/src/libcore/lib.rs:67 #![feature(old_impl_check)]
                                                                ^~~~~~~~~~~~~~
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: self.raw.hash != self.hashes_end', /home/lbruno/src/upstream/rust/src/libstd/collections/hash/table.rs:773

stack backtrace:
   1:     0x7f08410b10d0 - sys::backtrace::write::h7de15137e855e83cSZt
   2:     0x7f08410d46d0 - failure::on_fail::h4da67e6a3668b239LdA
   3:     0x7f084103f250 - rt::unwind::begin_unwind_inner::h4bd6f5432ad47c00MSz
   4:     0x7f08404aa060 - rt::unwind::begin_unwind::h2320400940752561500
   5:     0x7f08404d15d0 - std..collections..hash..table..RawTable<syntax..ast..Name, (*>::glue_drop.15213::h030c3ec61502adc2
   6:     0x7f08404e4de0 - std..collections..hash..table..RawTable<u32, std..collections..hash..set..HashSet<u32, std..collections..hash..state..DefaultState<rustc..util..nodemap..FnvHasher>>>::glue_drop.15492::h6fcebb91da1f811c
   7:     0x7f084051d520 - Resolver::glue_drop.16400::h8fc30f1baa57af04                                                                                    
   8:     0x7f084051cdf0 - resolve_crate::hbba1f75a4c654450sDi                                                                                             
   9:     0x7f0841623cd0 - driver::phase_3_run_analysis_passes::hdbd523b0dece3c48VFa                                                                       
  10:     0x7f084160bcf0 - driver::compile_input::h36e27867556156cbBba                                                                                     
  11:     0x7f08416d4c80 - run_compiler::hd967642577394639R8b                                                                                              
  12:     0x7f08416d33f0 - thunk::F.Invoke<A, R>::invoke::h4176026213811984                                                                                
  13:     0x7f08416d22f0 - rt::unwind::try::try_fn::h12294395349683804038
  14:     0x7f0841149850 - rust_try_inner
  15:     0x7f0841149840 - rust_try
  16:     0x7f08416d25a0 - thunk::F.Invoke<A, R>::invoke::h18028537340176081056
  17:     0x7f08410c20f0 - sys::thread::thread_start::h9e40879762be7137aPw
  18:     0x7f083bd3cfe0 - start_thread
  19:     0x7f0840ccac99 - __clone
  20:                0x0 - <unknown>

/home/lbruno/src/upstream/rust/mk/target.mk:165: recipe for target 'x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.core' failed
make: *** [x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.core] Error 101

[sylvestre]

I am experiencing the same issue with LLVM Debian packages (3.5.1-1~exp1)

[lucab]

This seems related to how your LLVM is compiled (thanks @flaper87 and @sylvestre for testing).
In brief, we found that the following combinations work:

• LLVM 3.5.x without --enable-optimized
• LLVM 3.5.x with --enable-optimized and this lifetime patch

This means both that rust should work with a vanilla LLVM 3.5.x, but that it doesn't work with debian one (as it is compiled with the switch and without that patch).

[flaper87]

@lucab I can confirm that it works with llvm>=3.5.x.

Also, I'm having issues on getting it to compile with fedora's package. There's probably something going on with the flags fedora uses. I'll check in more details soon.

[lucab]

But then clearly we hit #15793, whose fix is not for 3.5.x and also introduces an API change.
Really, I start thinking that supporting 3.4+ as @alexcrichton suggested is much more cumbersome than expected and anyway will never work, as rust keep pushing the limits of LLVM.

I personally think that following @brson suggestions makes more sense: focus on 3.6 compatibility while we are still in time, and drop the rest which is anyway known to be non-working or producing bad code.

[flaper87]

@lucab it starts to seem so.

I personally think that following @brson suggestions makes more sense: focus on 3.6 compatibility while we are still in time, and drop the rest which is anyway known to be non-working or producing bad code.

I agree with the above as long as we keep support for llvm>=3.6 long enough to allow distros to maintain such version.

In addition to the above, once a distro has been released with a specific Rust version, it's likely to keep such version and just update minor points (which wouldn't break llvm's compatibility).

[sanxiyn]

LLVM seems to do bug-fix releases for stable branches these days. (3.4.1 and 3.4.2.) Can we get some fixes into 3.5.1, for example?

[flaper87]

@sanxiyn if we get the required fixes into say 3.5.2, I think it won't be hard for existing llvm packages based on 3.5.x to rebase on top of that version.

[lucab]

@sanxiyn In theory it should be feasible, yes, but we have to pester upstream a bit about it and see how long they want to maintain old branches. I don't know their stable policy, but I think they mostly aren't too focused on backporting stuff.

In practice, however, please consider that:

• the two bug-reports and patches above originated from rust, and nobody really cared about having them backported anywhere
• LLVM just released 3.5.1, and we missed that train. they are now going for 3.6.0, not sure how many people will be interested in a 3.5.2 (but I guess few)

We (as downstream packager) crearly don't have enough manpower (nor knowledge) to review every commit on both rust and llvm, and pester for backports. I'm focusing on 3.6 right now.

[sylvestre]

We, LLVM, are planning to make a 3.5.2. Drop an email to thomas.stellard@amd.com. He is the 3.5.X release manager.

[flaper87]

@sylvestre awesome news, thanks for the heads up.

[lucab]

I've pinged him (plus code owners) via mail asking for backports. I'll keep you posted on the updates.