Open
Description
Reproduction is in Custom MIR. Not sure if this can be triggered from surface rust
#![feature(custom_mir, core_intrinsics)]
extern crate core;
use core::intrinsics::mir::*;
#[custom_mir(dialect = "runtime", phase = "initial")]
pub fn fn13(mut _7: i8) {
mir! {
let _25: i16;
let _31: (i128, i16);
let _39: i16;
{
_31.1 = _7 as i16;
_25 = _31.1 * _31.1;
_31 = (50414009528881047150422352225052180952_i128, _25);
_25 = _31.1 >> _31.0;
Goto(bb17)
}
bb17 = {
Call(_39 = std::hint::black_box(_25), ReturnTo(bb18), UnwindUnreachable())
}
bb18 = {
Return()
}
}
}
pub fn main() {
fn13(0);
}
$ rustc-clif -Zmir-opt-level=0 -Copt-level=3 929244-debug.rs
thread '<unnamed>' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cranelift-codegen-0.104.0/src/machinst/lower.rs:766:21:
should be implemented in ISLE: inst = `v12 = smulhi.i8 v0, v0`, type = `Some(types::I8)`
stack backtrace:
0: 0x7ffff978bf86 - std::backtrace_rs::backtrace::libunwind::trace::h514ead2753e1782f
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
1: 0x7ffff978bf86 - std::backtrace_rs::backtrace::trace_unsynchronized::hbc462e8372651887
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7ffff978bf86 - std::sys_common::backtrace::_print_fmt::he3092ef183bdd613
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/sys_common/backtrace.rs:68:5
3: 0x7ffff978bf86 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h908f80a389799910
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/sys_common/backtrace.rs:44:22
4: 0x7ffff97de880 - core::fmt::rt::Argument::fmt::ha9f3d8b02e25296c
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/core/src/fmt/rt.rs:142:9
5: 0x7ffff97de880 - core::fmt::write::hef880bc86bd63d4b
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/core/src/fmt/mod.rs:1120:17
6: 0x7ffff977f94f - std::io::Write::write_fmt::h780869503f755b5a
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/io/mod.rs:1810:15
7: 0x7ffff978bd64 - std::sys_common::backtrace::_print::h52cc78326ec17ac5
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/sys_common/backtrace.rs:47:5
8: 0x7ffff978bd64 - std::sys_common::backtrace::print::h44b4c057fd1c7c3f
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/sys_common/backtrace.rs:34:9
9: 0x7ffff978eaf7 - std::panicking::default_hook::{{closure}}::h99cbf699c09f8685
10: 0x7ffff978e859 - std::panicking::default_hook::hbc89d54398681576
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/panicking.rs:292:9
11: 0x7ffffc54acec - std[1d0ea5b5e602c844]::panicking::update_hook::<alloc[d84df3010862da1b]::boxed::Box<rustc_driver_impl[2078f68ece4ea2b8]::install_ice_hook::{closure#0}>>::{closure#0}
12: 0x7ffff978f246 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h99950b3f8a1ddee8
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/alloc/src/boxed.rs:2029:9
13: 0x7ffff978f246 - std::panicking::rust_panic_with_hook::he160495ec53b11e6
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/panicking.rs:785:13
14: 0x7ffff978ef92 - std::panicking::begin_panic_handler::{{closure}}::ha86f6320ad4cac49
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/panicking.rs:659:13
15: 0x7ffff978c486 - std::sys_common::backtrace::__rust_end_short_backtrace::h19c3911246e5b7ea
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/sys_common/backtrace.rs:171:18
16: 0x7ffff978ece4 - rust_begin_unwind
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/panicking.rs:647:5
17: 0x7ffff97daf85 - core::panicking::panic_fmt::hd869deda4756f0c1
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/core/src/panicking.rs:72:14
18: 0x7ffff06f38f8 - cranelift_codegen::machinst::lower::Lower<I>::lower::hf5680db6e8da6825
19: 0x7ffff05d6739 - cranelift_codegen::machinst::compile::compile::h5311fd7207db3d5c
20: 0x7ffff06936f5 - <cranelift_codegen::isa::x64::X64Backend as cranelift_codegen::isa::TargetIsa>::compile_function::h590f11e5c6d2c4ff
21: 0x7ffff0709f5b - cranelift_codegen::context::Context::compile_stencil::h96dc3cd783467e94
22: 0x7ffff0709c37 - cranelift_codegen::context::Context::compile_and_emit::h593fc7e7957fe7fc
23: 0x7ffff0499eca - <cranelift_object::backend::ObjectModule as cranelift_module::module::Module>::define_function_with_control_plane::hc9ac75d45c4de148
24: 0x7ffff03e4ec3 - cranelift_module::module::Module::define_function::hb378a4ac6a6da2a5
25: 0x7ffff046fd8d - rustc_codegen_cranelift::base::compile_fn::he5118887952ffc76
26: 0x7ffff042c8ab - std::sys_common::backtrace::__rust_begin_short_backtrace::h37b57af66c3e318c
27: 0x7ffff0429604 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hb385e8dc4fe3342d
28: 0x7ffff9798835 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hba0b80fd74ce5417
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/alloc/src/boxed.rs:2015:9
29: 0x7ffff9798835 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h0ab2d213dcdff51c
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/alloc/src/boxed.rs:2015:9
30: 0x7ffff9798835 - std::sys::pal::unix::thread::Thread::new::thread_start::h7eeca5a8e186b7ad
at /rustc/e7bbe8ce933123a8e327c79e38bcb790595e6a65/library/std/src/sys/pal/unix/thread.rs:108:17
31: 0x7ffff9586897 - start_thread
32: 0x7ffff960d564 - __GI___clone
33: 0x0 - <unknown>
error: the compiler unexpectedly panicked. this is a bug.
note: using internal features is not supported and expected to cause internal compiler errors when used incorrectly
note: please attach the file at `/root/rustlantis-repros/rustc-ice-2024-02-03T11_40_43-99834.txt` to your bug report
note: compiler flags: -C panic=abort -Z panic-abort-tests -Z codegen-backend=/root/rustc_codegen_cranelift/dist/lib/librustc_codegen_cranelift.so -Z mir-opt-level=0 -C opt-level=3
query stack during panic:
end of query stack
warning: 2 warnings emitted
On latest cdae185
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
bjorn3 commentedon Feb 3, 2024
It looks like you are multiplying a 128bit integer with a 16bit integer. I don't think that is possible in surface rust. Probably something the MIR verifier should be made to deny.
cbeuw commentedon Feb 3, 2024
By multiplying I assume you meant shift right?
Shr
in MIR is documented with "The offset is truncated to the size of the first operand and made unsigned before shifting."This surface Rust also triggers the same panic (though it has UB):
bjorn3 commentedon Feb 3, 2024
I misread the
_25 = _31.1 * _31.1;
(i16 times itself) as_25 = _31.0 * _31.1;
(i128 times i16).The only place where cg_clif emits an
smulhi
is when multiplying with the left hand side being a 128bit integer:rustc_codegen_cranelift/src/num.rs
Line 257 in cdae185
I see. It doesn't have UB by the way. There is no unsafe code. Shifting with overflow is defined as panicking at runtime. The lint you suppressed only triggers when rustc knows the shift amount at compile time already.
In any case I can't reproduce this error on aarch64-unknown-linux-gnu, but I can reproduce it on x86_64-unknown-linux-gnu. It seems to be a Cranelift issue. I reduced it to:
bjorn3 commentedon Feb 3, 2024
I've reported this upstream at bytecodealliance/wasmtime#7865. Thanks for reporting this to me!
matthiaskrgr commentedon Feb 12, 2024
I've found something similar involving simd stuff, might be related:
auto-reduced (treereduce-rust):
original code
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustc -Zcodegen-backend=cranelift
Program output
bjorn3 commentedon Mar 9, 2024
The multiplication issue has been fixed.
@matthiaskrgr I can't reproduce your crash. I had to change it to
as
extern "platform-intrinsics"
is now gone.matthiaskrgr commentedon Mar 9, 2024
is this an x86 thing again? 😅
with #1455 (comment)
rustc a.rs -Zcodegen-backend=cranelift
bjorn3 commentedon Mar 9, 2024
Yes, it reproduces on x86_64.
bjorn3 commentedon Mar 9, 2024
I'm not sure if f32x2 is allowed at all by the x86_64 systemv calling convention. It is on aarch64 though (
float32x2_t
inarm_neon.h
for C).bjorn3 commentedon Mar 9, 2024
In any case I opened bytecodealliance/wasmtime#8075 to suggest adding
load.f32x2
support.