Repository navigation
ICE during cross-compilation and const eval #49033
Description
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
Activity
oli-obk commentedon Mar 15, 2018
OK this is weird. It looks like the metadata contains
u32::max_value() - 1, even though it should beu64::max_value() - 1, because usize on the host machine isu64.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 commentedon 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 commentedon 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
nikomatsakis commentedon Mar 15, 2018
triage: P-high
don't test --target=i686-unknown-linux-gnu for now, due to rust-lang/…
Auto merge of #49079 - oli-obk:cross_miri, r=michaelwoerister
Unpin nightly version in CI.