-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Miscompilation on aarch64-apple-darwin (likely a calling convention bug) #112548
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
@rustbot label O-aarch64 O-macos |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high |
I have another reproduction of what I believe is the same bug, but this one is only 34 lines, has only safe code and doesn't need a hasher: use std::fmt::Debug;
pub fn dump_var<T: Debug>(
f: usize,
var0: usize,
val0: T,
var1: usize,
val1: i32,
var2: usize,
val2: i32,
var3: usize,
val3: i32,
) {
println!(
"fn{f}:_{var0} = {val0:?}\n_{var1} = {val1:?}\n_{var2} = {val2:?}\n_{var3} = {val3:?}"
);
}
fn fn10() {
let _2 = 302053680377554952743809083898710279615_u128;
let mut _5 = _2.wrapping_shl(_2 as u32);
let mut _18: (u128, [isize; 3]) = (0, [0; 3]);
_18.1 = [9223372036854775807_isize; 3];
dump_var(11, 0, 0, 0, 0, 0, 0, 0, 0);
dump_var(11, 0, 0, 0, 0, 0, 0, /* addend */ 1, 0);
let _1 = _5 | _18.0;
let _11 = _5.wrapping_mul(_1);
_5 = _11;
dump_var(10, 5, _5, 0, 0, 0, 0, 0, 0);
}
pub fn main() {
fn10();
} This should print fn11:_0 = 0
_0 = 0
_0 = 0
_0 = 0
fn11:_0 = 0
_0 = 0
_0 = 0
_1 = 0
fn10:_5 = 85070591730234615865843651857942052864
_0 = 0
_0 = 0
_0 = 0 but with % rustc -Zmir-opt-level=0 -Copt-level=3 repro.rs && ./repro
fn11:_0 = 0
_0 = 0
_0 = 0
_0 = 0
fn11:_0 = 0
_0 = 0
_0 = 0
_1 = 0
fn10:_5 = 85070591730234615865843651857942052865
_0 = 0
_0 = 0
_0 = 0 The value of |
Any chance that the fix for #112767 also fixes this one? Looks kinda similar to me. |
No it fixes neither program in this issue. llvm/llvm-project#63475 might be related, since it also passes a vector on the stack |
Does this issue still reproduce? |
Running on an MBP M1, with rustc 1.81.0-nightly (8337ba9 2024-06-12), I get the same hash output for both of the executions listed:
|
@alex Thanks! Would you mind also trying the other test case in #112548 (comment)? |
That version does reproduce the issue:
|
Thanks! |
I can reproduce this. |
Upstream issue: llvm/llvm-project#97147. |
@rustbot label +llvm-fixed-upstream |
Update LLVM submodule Fixes rust-lang#112548 and unlock rust-lang#125642. r? `@cuviper` or `@nikic`
Rollup merge of rust-lang#127190 - DianQK:llvm-backport, r=nikic Update LLVM submodule Fixes rust-lang#112548 and unlock rust-lang#125642. r? ``@cuviper`` or ``@nikic``
Fuzzer generated code:
This should output
15917201677548574216
: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a51ce49127180037639732b4a990ddbe.But on
-Zmir-opt-level=0 -Copt-level>=1
it prints something different.-Zmir-opt-level>=1
masks the bug.This is only reproducible on
aarch64-apple-darwin
, but not onx86_64-apple-darwin
oraarch64-unknown-linux-gnu
. The reproducer is very sensitive to small changes. For instance, changing the length of_23
infn16
to8
prevents the bug. For these reasons I suspect it's an Apple Silicon specific calling convention bug leading to some stack corruption.The text was updated successfully, but these errors were encountered: