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 [email protected]. 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.

[dotdash]

@lucab What's the status on the backports? The window for 3.5.2 closes on the 16th.

[lucab]

I didn't get any answer to my original mail. Maybe it's better if you bring this to the ML?

[dotdash]

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150309/265717.html

[lucab]

I'm probably just missing it, but what about #15793 and http://reviews.llvm.org/D4595?

[dotdash]

I'm torn on that one. We hit that because of the noalias and alias_scope metadata, which was introduced in 3.6. Since we don't emit TBAA metadata, it doesn't affect us (yet).

[lucab]

I don't exactly remember the details now, but I'm quite sure that only with the minimal lifetime backport on top of vanilla 3.5, issue-15793.rs test was reliably failing. Is the full testsuite passing for you?

[dotdash]

sigh We'd at least also need the fix for #21721 and I accidently broke some 3.5 compat when I updated our fork to 3.6 (which currently stops me from checking if issue-15793.rs works).

Before I spend even more time on trying to fix this, I'd like to ask for some "official" stance on supporting older LLVM versions. 3.4 lacks the fix for #21721 so I guess we can just forget about that and rip out our support for compiling against it. But what about 3.5? Do we want to spend the time required to get that working again (at least until we trigger the next bug)?

@brson, @alexcrichton what do you think?

[alexcrichton]

We've never really had an officially supported version of LLVM just yet, we've largely just tracked whatever's "close to master" as far as I know. I would personally love to stick to 3.6 as long as possible (moving to 3.7 but maintaining 3.6 compatibility when it comes out) but I don't think we're willing at this point to commit to maintaining 3.6 compatibility.

So I guess to answer your question I'm not sure if it would be all that worth it to invest effort in compatibility with 3.5 (especially with no regression tests). Right now we only "officially support" our own fork which is "pretty close" to 3.6, but this situation could always change over time! I'd love to start adding some bots to gate against older LLVM versions :)

[dotdash]

I at least asked for the fix for #21721 to go into 3.5.2, let's see.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150309/265961.html

[tamird]

Can this be closed now that LLVM 3.5.2 is out?

[alexcrichton]

Closing as it looks like this was fixed upstream