ICE: repr align with extern "C" functions ().

[matthewjasper]

The following code ICEs on x86_64 linux

#![feature(repr_align)]
#![feature(attr_literals)]

#[repr(align(16))]
pub struct A {
    y: i64, // Can be any type
}

pub extern "C" fn foo(x: A) {}

Suspect that it's this line (expecting that a struct with size > 8 has > 1 field)

rust/src/librustc_trans/cabi_x86_64.rs

Line 199 in 8b22e70

let hi = reg_component(cls, &mut i, size - offset).unwrap();

ICE message:

error: internal compiler error: unexpected panic

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: rustc 1.22.0-nightly (8493813cd 2017-10-22) running on x86_64-unknown-linux-gnu

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

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:335:20
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:69
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:58
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:391
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:498
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:71
   9: core::panicking::panic
             at /checkout/src/libcore/panicking.rs:51
  10: _ZN11rustc_trans11cabi_x86_6416compute_abi_info28_$u7b$$u7b$closure$u7d$$u7d$17h9fac6bc7bad7473bE.llvm.D51027F6
  11: _ZN11rustc_trans3abi6FnType14adjust_for_abi17h1b7f713077d90b22E.llvm.795B9FFD
  12: rustc_trans::declare::declare_fn
  13: rustc_trans::trans_item::predefine_fn
  14: rustc_trans::trans_item::TransItemExt::predefine
  15: _ZN11rustc_trans4base20compile_codegen_unit17h362937ee897385e2E.llvm.FBB1C193
  16: rustc::ty::maps::<impl rustc::ty::maps::queries::compile_codegen_unit<'tcx>>::compute_result
  17: rustc::dep_graph::graph::DepGraph::with_task
  18: rustc_errors::Handler::track_diagnostics
  19: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check
  20: _ZN5rustc2ty4maps80_$LT$impl$u20$rustc..ty..maps..queries..compile_codegen_unit$LT$$u27$tcx$GT$$GT$5force17h9c0ad53b14788757E.llvm.83EA5DAA
  21: rustc::ty::maps::<impl rustc::ty::maps::queries::compile_codegen_unit<'tcx>>::try_get
  22: rustc::ty::maps::TyCtxtAt::compile_codegen_unit
  23: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::compile_codegen_unit
  24: rustc_trans::base::trans_crate
  25: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
  26: rustc::util::common::time
  27: rustc_driver::driver::phase_4_translate_to_llvm
  28: _ZN12rustc_driver6driver13compile_input28_$u7b$$u7b$closure$u7d$$u7d$17h7eb7268ddd3dec6bE.llvm.5A1A36ED
  29: <std::thread::local::LocalKey<T>>::with
  30: <std::thread::local::LocalKey<T>>::with
  31: rustc_driver::driver::compile_input
  32: rustc_driver::run_compiler

cc #33626

[matthewjasper]

This isn't fixed, example should have had a #![crate_type = "lib"] or a #[no_mangle] attribute to make sure that the function is exported.
@estebank

[estebank]

@matthewjasper confirmed.

CC @topecongiro.

[eddyb]

Suspect that it's this line (expecting that a struct with size > 8 has > 1 field)

These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.