Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICE during cross-compilation and const eval #49033

Closed
alexcrichton opened this issue Mar 15, 2018 · 4 comments · Fixed by #49079
Closed

ICE during cross-compilation and const eval #49033

alexcrichton opened this issue Mar 15, 2018 · 4 comments · Fixed by #49079
Assignees
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

Looks like today's nightly unfortunately contains a regression from #46882 (confirmed locally) which causes rustc to ICE specifically when cross-compiling

#![crate_type = "rlib"]
pub fn foo() {
    std::env::consts::ARCH;
}
$ RUST_BACKTRACE=1 rustc src/lib.rs --target i686-unknown-linux-gnu
warning: path statement with no effect
 --> src/lib.rs:3:5
  |
3 |     std::env::consts::ARCH;
  |     ^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(path_statements)] on by default

thread 'rustc' panicked at 'slice index starts at 4294967295 but ends at 8288060', libcore/slice/mod.rs:791:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:403
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:349
   7: rust_begin_unwind
             at libstd/panicking.rs:325
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:72
   9: core::slice::slice_index_order_fail
             at libcore/slice/mod.rs:791
  10: <serialize::opaque::Decoder<'a> as serialize::serialize::Decoder>::read_usize
  11: <rustc_metadata::decoder::DecodeContext<'a, 'tcx> as serialize::serialize::SpecializedDecoder<rustc::mir::interpret::AllocId>>::specialized_decode
  12: <rustc_metadata::decoder::DecodeContext<'a, 'tcx> as serialize::serialize::SpecializedDecoder<rustc::mir::interpret::AllocId>>::specialized_decode
  13: <rustc::mir::interpret::MemoryPointer as serialize::serialize::Decodable>::decode::{{closure}}
  14: serialize::serialize::Decoder::read_enum_variant
  15: serialize::serialize::Decoder::read_enum_variant
  16: serialize::serialize::Decoder::read_enum_variant
  17: <rustc::mir::Operand<'tcx> as serialize::serialize::Decodable>::decode
  18: serialize::serialize::Decoder::read_seq
  19: <rustc::mir::Mir<'tcx> as serialize::serialize::Decodable>::decode::{{closure}}
  20: rustc_metadata::decoder::<impl rustc_metadata::cstore::CrateMetadata>::maybe_get_optimized_mir
  21: rustc_metadata::cstore_impl::provide_extern::optimized_mir
  22: rustc::dep_graph::graph::DepGraph::with_task_impl
  23: rustc::ty::maps::<impl rustc::ty::maps::queries::optimized_mir<'tcx>>::force
  24: rustc::ty::maps::<impl rustc::ty::maps::queries::optimized_mir<'tcx>>::try_get
  25: rustc::ty::maps::TyCtxtAt::optimized_mir
  26: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::maybe_optimized_mir
  27: <rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::load_mir
  28: rustc_mir::interpret::const_eval::eval_body_and_ecx::{{closure}}
  29: rustc_mir::interpret::const_eval::eval_body_and_ecx
  30: rustc_mir::interpret::const_eval::const_eval_provider
  31: rustc::dep_graph::graph::DepGraph::with_task_impl
  32: rustc::ty::maps::<impl rustc::ty::maps::queries::const_eval<'tcx>>::force
  33: rustc::ty::maps::<impl rustc::ty::maps::queries::const_eval<'tcx>>::try_get
  34: rustc::ty::maps::TyCtxtAt::const_eval
  35: <rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::const_eval
  36: <rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::read_global_as_value
  37: <rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::eval_operand
  38: <rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::eval_rvalue_into_place
  39: rustc_mir::interpret::const_eval::eval_body_and_ecx::{{closure}}
  40: rustc_mir::interpret::const_eval::eval_body_and_ecx
  41: rustc_mir::interpret::const_eval::const_eval_provider
  42: rustc::dep_graph::graph::DepGraph::with_task_impl
  43: rustc::ty::maps::<impl rustc::ty::maps::queries::const_eval<'tcx>>::force
  44: rustc::ty::maps::<impl rustc::ty::maps::queries::const_eval<'tcx>>::try_get
  45: rustc::ty::maps::TyCtxtAt::const_eval
  46: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::const_eval
  47: rustc_mir::transform::const_prop::ConstPropagator::eval_constant
  48: <rustc_mir::transform::const_prop::ConstPropagator<'b, 'a, 'tcx> as rustc::mir::visit::Visitor<'tcx>>::visit_statement
  49: <rustc_mir::transform::const_prop::ConstProp as rustc_mir::transform::MirPass>::run_pass
  50: rustc_mir::transform::optimized_mir::{{closure}}
  51: rustc_mir::transform::optimized_mir
  52: rustc::dep_graph::graph::DepGraph::with_task_impl
  53: rustc::ty::maps::<impl rustc::ty::maps::queries::optimized_mir<'tcx>>::force
  54: rustc::ty::maps::<impl rustc::ty::maps::queries::optimized_mir<'tcx>>::try_get
  55: rustc::ty::maps::TyCtxtAt::optimized_mir
  56: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::instance_mir
  57: rustc_mir::monomorphize::collector::collect_items_rec
  58: rustc_mir::monomorphize::collector::collect_crate_mono_items
  59: rustc_trans::base::collect_and_partition_translation_items
  60: rustc::dep_graph::graph::DepGraph::with_task_impl
  61: rustc::ty::maps::<impl rustc::ty::maps::queries::collect_and_partition_translation_items<'tcx>>::force
  62: rustc::ty::maps::<impl rustc::ty::maps::queries::collect_and_partition_translation_items<'tcx>>::try_get
  63: rustc::ty::maps::TyCtxtAt::collect_and_partition_translation_items
  64: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::collect_and_partition_translation_items
  65: rustc_trans::base::trans_crate
  66: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
  67: rustc_driver::driver::phase_4_translate_to_llvm
  68: rustc_driver::driver::compile_input::{{closure}}
  69: rustc::ty::context::TyCtxt::create_and_enter
  70: rustc_driver::driver::compile_input
  71: rustc_driver::run_compiler

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.26.0-nightly (c90f68224 2018-03-08) running on x86_64-unknown-linux-gnu

cc @oli-obk

@alexcrichton alexcrichton added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Mar 15, 2018
alexcrichton added a commit to alexcrichton/cargo that referenced this issue Mar 15, 2018
@oli-obk oli-obk self-assigned this Mar 15, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Mar 15, 2018

OK this is weird. It looks like the metadata contains u32::max_value() - 1, even though it should be u64::max_value() - 1, because usize on the host machine is u64.

See https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/decoder.rs#L285 for the decoding and https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/encoder.rs#L217 for the encoding.

The target bitwidth should not influence usize serialization to metadata, right?

Or is the libstd built on i686 and now read on x86_64? That would mean we should investigate all uses of usize/isize serialization in metadata, because they all may have similar problems.

I'll fix it on Friday, until then, anyone can fix this by making 0 and 1 reserved indices instead of usize::max_value and its predecessor

@oli-obk
Copy link
Contributor

oli-obk commented Mar 15, 2018

Or, just use u32 instead of usize, which means that 64 bit hosts can have a maximum of 2^32 allocations that go into metadata. We can then revisit when it becomes an issue because we run out of indices

@oli-obk
Copy link
Contributor

oli-obk commented Mar 15, 2018

Ah no, I misunderstood, there's no metadata file that can be bigger than 4 gigabytes. We should probably forbid encoding usize to metadata with a specialized encoder that panics. Because any metadata file that's bigger than 4GB will cause similar errors to pop up

@alexcrichton alexcrichton added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 15, 2018
@nikomatsakis
Copy link
Contributor

triage: P-high

@rust-highfive rust-highfive added the P-high High priority label Mar 15, 2018
bors added a commit that referenced this issue Mar 19, 2018
Cleanup metadata and incremental cache processing of constants

fixes #49033
fixes #49081

we really need tests for this. do we have any cross compilation tests? I couldn't find any
ehuss added a commit to ehuss/cargo that referenced this issue Apr 5, 2018
Removes temporary workaround for rust-lang/rust#49033.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants