Repository navigation
Miscompilation in simple rust program, since rust 1.99.0(nightly-2026-08-06), difference between none and opt-level=1 optimization #164667
Description
I tried this code:
use std::hint::black_box as a;
fn main() {
let b: i8 = a(0);
let a = a(1);
let a = (-2i128).rotate_right(1).checked_mul(a).unwrap_or(0);
print!("{}", a);
let a = (b as u128).abs_diff(b as u16 as u128);
print!("{}", a)
}Compiled with
rustc reduced.rs
it prints
1701411834604692317316873037158841057270
but compiled with
rustc reduced.rs -C opt-level=1
it prints
1701411834604692317316873037158841057271
Meta
rustc --version --verbose:
rustc 1.99.1 (58cf8f9c3 2026-10-13)
binary: rustc
commit-hash: 58cf8f9c35b355199727627d07ae34a4e2846d67
commit-date: 2026-10-13
host: x86_64-unknown-linux-gnu
release: 1.99.1
LLVM version: 23.1.1
Problem was found by a rust fuzzer (created by an LLM) - https://github.com/qarmin/rs-compiler-fuzzer
| channel | reproducible |
|---|---|
| stable (rustc 1.99.1 (58cf8f9 2026-10-13)) | yes |
| beta (rustc 1.100.0-beta.7 (fd8e211 2026-10-17)) | yes |
| nightly (rustc 1.101.0-nightly (07e526d 2026-10-19)) | yes |
| stable 1.98.0 (rustc 1.98.0 (88d9e12 2026-08-18)) | no |
| stable 1.99.0 (rustc 1.99.0 (b940084 2026-09-28)) | yes |
| nightly-2026-08-05 (rustc 1.99.0-nightly (1ed2df6 2026-08-04)) | no |
| nightly-2026-08-06 (rustc 1.99.0-nightly (7608eb7 2026-08-05)) | yes |
Activity
[-]Miscompilation in simple rust program, since rust 1.99.0(nightly-2026-08-06), with and without `opt-level=1` optimization[/-][+]Miscompilation in simple rust program, since rust 1.99.0(nightly-2026-08-06), difference between none and `opt-level=1` optimization[/+]saethlin commentedon Oct 21, 2026
Checking a smattering of stable/beta/nightly versions is not informative, I know our default issue template asks you to check stable/beta/nightly but if you are capable of doing so (you're running a fuzzer, so clearly you are capable) bisecting is more useful. In this case, bisection points to #158734, the LLVM 23 upgrade.
In addition, please check perhaps as part of your differential testing, if a miscompile is caused by LLVM or by a MIR optimization (this is often as easy a checking if the bug reproduces with -Zmir-opt-level=0).
D3athSkulll commentedon Oct 21, 2026
Hey @qarmin @saethlin , I am interested in taking this issue. Have investigated it further from my end. On reproducing the miscompilation for
-C opt-level=1. The LLVM pass number 1036 is creating issue specificallystack-coloringpass. On generating the machine instructions I see a incorrect stack slot reuse which involves value with address being passed through a black box.I would prefer trying lifetime analysis here and bug persists with -Zmir-opt-level=0, which argues against MIR optimization as the cause.
apiraino commentedon Oct 21, 2026
if the issue lies in the LLVM upgrade, as the bisection seems to demonstrate, wouldn't be more helpful to file an issue upstream? I know that we try to stay close to LLVM.
(what is a "LLVM pass number 1036"?)
D3athSkulll commentedon Oct 21, 2026
LLVM pass number 1036 is the position of the faulty pass in the LLVM verbose execution log, in the reproducer which is triggering our miscompilation. The pass name is “Merge disjoint stack slots (stack-coloring)” which analyses stack slot lifetimes and merges the slots whose live ranges do not overlap to allow memory reuse.
saethlin commentedon Oct 21, 2026
You are having this conversation on the wrong issue tracker, with the wrong people, and in any case I would advise against a first-time contributor trying to fix a miscompile unless you have previous experience working on compiler optimizations.
maxdexh commentedon Oct 21, 2026
You are quite welcome to file an issue on the LLVM side though ^^
D3athSkulll commentedon Oct 22, 2026
Hey @qarmin did you file an issue on LLVM side in the repository? Or would you have me file one as I do have some info to file and try decoding it further
theemathas commentedon Oct 22, 2026
@D3athSkulll I believe they didn't.