rustc 32bits takes one hour to compile with optimisations on

[tomaka]

EDIT: only happens with the 32bits version, 64bits version works.

Similar to #24600, but at a different step.
To reproduce: clone https://github.com/tomaka/glium/tree/aae2129a279c80a022e940393c54462b5d8df99c and run cargo run --release.

Compiling with opt-level=0 doesn't hang. This is with opt-level=3.

The output of -Z time-passes:

time: 0.077     parsing
time: 0.000     recursion limit
time: 0.035     configuration 1
time: 0.001     gated macro checking
time: 0.000     crate injection
time: 0.012     macro loading
time: 0.000     plugin loading
time: 0.000     plugin registration
time: 0.949     expansion
time: 0.017     complete gated feature checking 1
time: 0.177     configuration 2
time: 0.089     maybe building test harness
time: 0.088     prelude injection
time: 0.008     checking that all macro invocations are gone
time: 0.018     complete gated feature checking 2
time: 0.095     assigning node ids and indexing ast
time: 0.015     external crate/lib resolution
time: 0.015     language item collection
time: 0.485     resolution
time: 0.017     lifetime resolution
time: 0.000     looking for entry point
time: 0.007     looking for plugin registrar
time: 0.061     region resolution
time: 0.007     loop checking
time: 0.007     static item recursion checking
time: 0.122     type collecting
time: 0.016     variance inference
time: 7.455     coherence checking
time: 17.105    type checking
time: 14.779    const checking
time: 0.154     privacy checking
time: 0.002     stability index
time: 0.054     intrinsic checking
time: 0.024     effect checking
time: 1.105     match checking
time: 0.065     liveness checking
time: 10.612    borrow checking
time: 6.440     rvalue checking
time: 0.036     reachability checking
time: 0.127     death checking
time: 1.140     stability checking
time: 0.000     unused lib feature checking
time: 1.631     lint checking
time: 0.000     resolving dependency formats
time: 14.050    translation
  time: 1.614   llvm function passes

(EDIT: I didn't wait long enough to have the rest, but it eventually works after one hour or so)

[tomaka]

Apparently some people can't reproduce.

I'm on Windows 7 with rustc 1.0.0-nightly (a52182ffd 2015-04-17) (built 2015-04-17).

[tomaka]

Same with rustc 1.0.0-nightly (00978a987 2015-04-18) (built 2015-04-19)

[bombless]

Cannot reproduce it with rustc 1.0.0-beta.2 (e9080ec39 2015-04-16) (built 2015-04-16).
I'm on Windows 8.1 64-bit.

[tomaka]

I think it's a 32bits vs 64bits problem. The two versions I used above are 32bits versions.
I tried the 64bits beta and it's working. Will try 64bits nightly later to confirm.

[tomaka]

Confirmed working with the 64bits nightly, so it's a 32bits-only problem.

[steveklabnik]

not exactly an ICE, but close enough for the tag

[vadimcn]

For me, building glium with cargo build --release on 1.0.0-beta.2 finished eventually, though LLVM module passes took more than an hour to complete.
I think this issue should be re-labeled I-compiletime (unless @tomaka has tried waiting that long).

[tomaka]

:O

I admit that I only waited around 45mn.

I used to compile glium with the 32bits rustc on release fairly often, and it took at most 5 minutes.

[bombless]

tips: use 64-bit version rustc to compile faster :)

Actually 64-bit rustc compiles about 3 times faster when bootstrapping.

[tomaka]

I can't use 64-bits rustc because I need to link to 32bits C libraries :(

[vadimcn]

64-bit rustc can generate 32-bit binaries, can't it?

[tomaka]

This problem is still around with the 2015-07-01 nightlies.

[arielb1]

It is LLVM that takes 1 hour ("LLVM module passes" - try with -Z time-passes) Are you sure there is no swapping going on (i.e. are you compiling on a machine with little memory)? My other guess is that LLVM does some bad OOM recovery.

It would be nice if you could try to compile with a cross rustc (that's a 64-bit rustc, but pass --target=i686-pc-linux-gnu and compile all libs manually), but that may be annoying, given that AFAIK Cargo doesn't support cross-compilation (and I am afraid that metadata currently depends on the source rustc architecture).

[tomaka]

I was going to investigate that, and it looks like the 07-07 nightlies no longer have this problem!

@arielb1 Thanks I guess :D