Rust nightly internal compiler error in x86 crate

[tgummerer]

I've been trying to compile the https://github.com/gz/rust-x86 crate with the latest nightly of rust, but have been getting the following internal compiler error:

$ RUST_BACKTRACE=1 cargo build                                          ∞
   Compiling x86 v0.9.0 (file:///home/tommy/dev/rust-x86)
error: internal compiler error: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc_trans/mir/operand.rs:83: not immediate: OperandRef(Ref((%"shared::segmentation::SegmentSelector"*:  %_4 = alloca %"shared::segmentation::SegmentSelector")) @ shared::segmentation::SegmentSelector)

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

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'Box<Any>', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/librustc_errors/lib.rs:423
stack backtrace:
   1:     0x7f7f8ff286bc - std::sys::imp::backtrace::tracing::imp::write::h9c41d2f69e5caabf
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x7f7f8ff36afe - std::panicking::default_hook::{{closure}}::hcc803c8663cda123
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x7f7f8ff366a3 - std::panicking::default_hook::hd5bda4e453dfb4be
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:361
   4:     0x7f7f8ff36f9b - std::panicking::rust_panic_with_hook::hffbc74969c7b5d87
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x7f7f8854fa37 - std::panicking::begin_panic::he43dc5d9a599d346
   6:     0x7f7f88565039 - rustc_errors::Handler::bug::h7088c6afc4a008fb
   7:     0x7f7f8d28090a - rustc::session::opt_span_bug_fmt::{{closure}}::hfd034971cdf18ea9
   8:     0x7f7f8d2803c5 - rustc::session::opt_span_bug_fmt::hc2cac313cb6d0020
   9:     0x7f7f8d280022 - rustc::session::bug_fmt::he01375c3004c5cfe
  10:     0x7f7f8f68001c - rustc_trans::mir::rvalue::<impl rustc_trans::mir::MirContext<'a, 'tcx>>::trans_rvalue::h7dc15384ecc85210
  11:     0x7f7f8f66bb8f - rustc_trans::mir::block::<impl rustc_trans::mir::MirContext<'a, 'tcx>>::trans_block::h31596f784d651219
  12:     0x7f7f8f669448 - rustc_trans::mir::trans_mir::h7e5fc59940d6977e
  13:     0x7f7f8f68a98b - rustc_trans::trans_item::TransItem::define::h929f421e720c71df
  14:     0x7f7f8f60b166 - rustc_trans::base::trans_crate::h496d157cb52a4b02
  15:     0x7f7f902f00b0 - rustc_driver::driver::phase_4_translate_to_llvm::h106eb073675c3bee
  16:     0x7f7f902c1e22 - rustc_driver::driver::compile_input::{{closure}}::heec508e3b0737586
  17:     0x7f7f902e3541 - rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}::haa13372f770e9055
  18:     0x7f7f90241319 - rustc::ty::context::TyCtxt::create_and_enter::h6acd1d75709e85e8
  19:     0x7f7f902bfdd0 - rustc_driver::driver::compile_input::h44853ffed84a12cb
  20:     0x7f7f90305034 - rustc_driver::run_compiler::hdc4bb0fcf7d0917a
  21:     0x7f7f90209c5b - std::panicking::try::do_call::h84a15e0d2b943318
  22:     0x7f7f8ff3fdda - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  23:     0x7f7f902339a2 - <F as alloc::boxed::FnBox<A>>::call_box::h61c78220cad685ea
  24:     0x7f7f8ff35954 - std::sys::imp::thread::Thread::new::thread_start::h76badbf9b0ecaf58
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/liballoc/boxed.rs:615
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys_common/thread.rs:21
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/thread.rs:84
  25:     0x7f7f87cfa453 - start_thread
  26:     0x7f7f8fbf97de - __GI___clone
  27:                0x0 - <unknown>

error: Could not compile `x86`.

To learn more, run the command again with --verbose.

This may be related to #38735, but looking at the code, however there is no "m" constraint anywhere in the SegmentSelector.

$ rustc --version
rustc 1.16.0-nightly (bf6d7b665 2017-01-15)
$ git rev-parse --short HEAD  # SHA-1 of the x86 crate
bb86b20

If I can help with any more details please let me know.

[nagisa]

Minimal:

#![crate_type="rlib"]
#![feature(asm)]

#[repr(C, packed)]
pub struct SegmentSelector {
    flags: u16
}

pub unsafe fn load_ss(sel: SegmentSelector) {
    asm!("movw $0, %ss " :: "r" (sel) : "memory");
}

Not a regression. Structures are consciously not considered to be immediates anymore as of #38906 and therefore cannot really be bound by the register bound. The structure should be converted to underlying value explicitly.

This is “just” an ICE.

That being said cc @dotdash @Mark-Simulacrum @eddyb.

[jackpot51]

@nagisa is it recommended to have explicit input registers such as "{ax}" when accessing segment registers to work around this ICE?

[nagisa]

@jackpot51 with asm! being an unstable feature that’s broken in many ways, anything goes. That being said, I feel like passing a plain integer may be a better solution compared to {ax} bound in various ways (e.g. does not increase register pressure unnecessarily).

[eddyb]

Does that work? (EDIT: as in, I can't see how anything like that could change the condition for thr ICE which is "structure used as immediate")
I believe what @nagisa is suggesting is to use sel.flags instead of sel.
We could maybe have a type whitelist for values that go through asm!, just like we do for C variadics.

[nagisa]

pub unsafe fn load_ss(sel: SegmentSelector) {
    asm!("movw $0, %ss " : "+*r" (&sel) :: "memory");
}

is a plausible workaround if you insist on using the r constraint with the structure.

[ashleygwilliams]

hey! so if you roll back to nightly-2017-01-12 you can get around this error for now, just tested this

[eddyb]

I would advise against rolling back as we are more likely to make the rules around asm! stricter.
And the fixes provided here work before the breaking change, too.

[steveklabnik]

@eddyb yeah, no plans to stay on the rolled back version, but would like to continue working today 😉

[eddyb]

Oh, it's not under your control so you can't just apply the fix, I missed that bit of context.

[phil-opp]

The x86 crate was fixed in gz/rust-x86#27. The crates.io versions were updated, too (0.8.1, 0.7.2 and 0.6.2).

[steveklabnik]

@nagisa 's reproduction fails to compile with

error[E0669]: invalid value for constraint in inline assembly
  --> src/lib.rs:10:34
   |
10 |     asm!("movw $0, %ss " :: "r" (sel) : "memory");
   |                                  ^^^

error: aborting due to previous error

closing!