ICE: librustc_trans/mir/constant.rs:682: Unexpected non-fat-pointer operand

[fenollp]

Here is the Travis job that fails: https://travis-ci.org/fenollp/minrs/jobs/190200414
Which is part of this build https://travis-ci.org/fenollp/minrs/builds/190200409

$ rustc --version
rustc 1.14.0 (e8a012324 2016-12-16)
$ cargo --version
cargo 0.15.0-nightly (298a012 2016-12-20)

This only happens on i686-apple-darwin & on Travis' OSX hardware.

Possibly linked: #38727 #16383 #37437 #38735

[nagisa]

Inline assembly cannot be an issue as this is an ICE on stable rustc. #38727 is fixed on nightly, so you’ll have to test/do travis run on i686 apple with nightly rustc.

[fenollp]

Here's a Travis run on nightly rustc with i686 apple platform: https://travis-ci.org/fenollp/minrs/jobs/190236515#L233

That bug looks fixed. However now I have

error: internal compiler error: /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/librustc_trans/mir/constant.rs:682: Unexpected non-fat-pointer operand

which Google doesn't seem to know about!

[nagisa]

cc @eddyb @Mark-Simulacrum stuff related to type_is_immediate change could have caused this.

[eddyb]

#38854 hasn't landed so it's not that. @dotdash may have also ran into this but I'm not sure.

[nikomatsakis]

So all it takes to reproduce is building https://github.com/fenollp/minrs on an i686-mac?

[nikomatsakis]

Or must it specifically be run on travis? If so, we should try to isolate what is different there!

[nikomatsakis]

Assigning to @pnkfelix for now, who will attempt to reproduce with a cross-compile.

[pnkfelix]

Summary: I have now managed to reproduce. Steps follow.

Initial comment: Hmm, well I think I have the cross-compile set up now (I wrote the steps I followed below), but I think I am hitting the first ICE described ("internal compiler error: ../src/librustc_trans/mir/operand.rs:82: impossible case reached"), so I have not yet replicated the "Unexpected non-fat-pointer operand").

Steps to set up cross compile

1. On a Mac, you need to make sure you have the ability to cross-compile to i686-apple-darwin. I used https://rustup.rs/ with a default of the nightly channel as an easy way to get that set up.

% rustup default nightly
% rustup target add i686-apple-darwin
%

2. With cross compiling support established, we do a build to demonstrate the ICE:

% cargo build -j1 --target i686-apple-darwin 
   [...]
   Compiling cocoa v0.5.2
error: internal compiler error: /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/librustc_trans/mir/operand.rs:82: impossible case reached

---

Update: but then again, with the stable channel I am hitting the same ICE ...? Maybe I still have something wrong here.

Update to update: I think I misread some of the initial discussion; the original description was filed against stable, so I cannot actually compare against a stable version because it is guaranteed to hit the described ICE. I'm going to see if changing my particular nightly changes anything here.

---

Okay, backtracking to the specific nightly of rustc from the time that this bug was filed has allowed me to replicate. (Also, doing a build for the host's x86_64-apple-darwin target did compile to the end successfully.)

So, how to do that:

% rustup default nightly-2017-01-08
% rustup target add i686-apple-darwin
% cargo build --target i686-apple-darwin
   [...]
   Compiling cocoa v0.3.3
error: internal compiler error: /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/librustc_trans/mir/constant.rs:682: Unexpected non-fat-pointer operand

[eddyb]

Can you use RUST_LOG=rustc_trans::base to reduce it to at least one function? (This works on release compilers too, I think, since it's info!)

[pnkfelix]

Talked to @eddyb on IRC. The last line of output from the rust log for rustc_trans::base is:

INFO:rustc_trans::base: trans_instance(<appkit::NSEventMask as std::fmt::Debug>::fmt::dummy::fmt)

[fenollp]

I noticed this before, might be of interest:

   Compiling cocoa v0.3.3

appears when the constant.rs bug gets triggered, however the operand.rs one has cocoa v0.5.2.

[eddyb]

@fenollp Ah that would definitely be able to trigger 2 distinct bugs.

[pnkfelix]

Okay here is a minimized example for the unexpected fat pointer operand ICE. It only comes up with i686 (-apple-darwin), though hopefully that is not relevant), not with x86_64

Code:

// This causeds an ICE when targeting i686-apple-darwin (from a
// x86_64-apple-darwin host).

#![crate_name = "cocoa"]
#![crate_type = "rlib"]

#![allow(non_upper_case_globals)]

pub mod appkit {
    use std::fmt::{self};

    #[repr(u64)]
    pub enum NSEventType {
        NSEventTypePressure = 34,
    }

    pub struct NSEventMask {
        bits: u64,
    }

    pub const NSEventMaskPressure: NSEventMask =
        NSEventMask{bits: 1 << (NSEventType::NSEventTypePressure as u64),};

    impl fmt::Debug for NSEventMask {
        fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
            if NSEventMaskPressure.bits != 0 {
                match f.write_str("NSEventMaskPressure") {
                    Ok(val) => val,
                    Err(err) => {
                        return Err(From::from(err))
                    }
                }
            }
            Ok(())
        }
    }
}

And here's the run:

% rustc --version
rustc 1.16.0-nightly (47c8d9fdc 2017-01-08)
% rustc /tmp/issue-38942.rs --target x86_64-apple-darwin
% rustc /tmp/issue-38942.rs --target i686-apple-darwin
error: internal compiler error: /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/librustc_trans/mir/constant.rs:682: Unexpected non-fat-pointer operand

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

thread 'rustc' panicked at 'Box<Any>', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/librustc_errors/lib.rs:423
note: Run with `RUST_BACKTRACE=1` for a backtrace.

% 

[pnkfelix]

Also reproduced minimized example still ICE's with a more recent nightly:

rustc 1.16.0-nightly (1a2ed98d3 2017-01-13)

[eddyb]

Oh this is a non-immediate CEnum, I bet #38854 fixes it, and I can't think of a nicer solution.

[nagisa]

The more-minimal version. Thanks for minimizing @pnkfelix!

#![crate_type = "rlib"]

#[repr(u64)]
pub enum NSEventType {
    NSEventTypePressure,
}

pub const A: u64 = NSEventType::NSEventTypePressure as u64;

fn banana() -> u64 {
    A
}

[pnkfelix]

(if #38854 does fix it, we probably should try to add this as a regression test if possible before closing, assuming we can readily do cross target unit test.)

[eddyb]

Do you even need the shift? I bet it's just the cast. The test doesn't need to be special as long as we build for 32-bit targets, it will get caught.

[nagisa]

Tried compiling the test case with compiler built from commit d70cd49 (inlcudes the #38854), but it still ICEs.

EDIT: never mind, it works. build system is weird.