Running this code in release mode fails:
main.rs:
use serde::Deserialize;
#[derive(Deserialize)]
pub struct TestExecutionPlan {
pub pos: usize,
/// List of actions to performs.
pub actions: Vec<String>,
pub expected_reboot: bool,
pub unexpected_reboot_count: u8,
pub failures: Vec<String>,
}
fn main() {
let config =
"{\"pos\":2,\"actions\":[],\"expected_reboot\":true,\"unexpected_reboot_count\":0,\"failures\":[]}";
let restored_plan: TestExecutionPlan =
serde_json5::from_str(config).expect("Expected a valid JSON config.");
assert_eq!(restored_plan.pos, 2);
}
.cargo/config.toml:
[target.x86_64-unknown-linux-gnu]
rustflags = [
"-Ccodegen-units=1",
]
Cargo.toml
[package]
name = "rust_playground"
version = "0.1.0"
edition = "2021"
[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json5 = "0.1"
When run with cargo run --release:
thread 'main' panicked at src/main.rs:18:5:
assertion `left == right` failed
left: 2
right: 2
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
This code passes under MIRI, so this is not the result of UB.
This does not repro on nightly, or even Fuchsia with the toolchain built upstream. We suspect that this may be because we set -Cpanic=abort on our toolchain, but we do have more differences from the upstream binaries. Edit: this turned out to be because we had -Ccodegen-units=1 set in our build.
We managed to bisect this in-tree down to #114048, which updated the LLVM submodule to 17.0.0. That, along with the nature of the bug, gives us confidence that this is likely a miscompile when using the codegen-units flag.
This reproduces with the latest nightly:
$ rustc --version
rustc 1.74.0-nightly (84a9f4c6e 2023-08-29)
as well as the nightly immediately after the LLVM upgrade:
$ rustc +nightly-2023-08-09 --version
rustc 1.73.0-nightly (f88a8b71c 2023-08-08)
Running this code in release mode fails:
main.rs:.cargo/config.toml:Cargo.tomlWhen run with
cargo run --release:This code passes under MIRI, so this is not the result of UB.
This does not repro on nightly, or even Fuchsia with the toolchain built upstream. We suspect that this may be because we setEdit: this turned out to be because we had-Cpanic=aborton our toolchain, but we do have more differences from the upstream binaries.-Ccodegen-units=1set in our build.We managed to bisect this in-tree down to #114048, which updated the LLVM submodule to 17.0.0. That, along with the nature of the bug, gives us confidence that this is likely a miscompile when using the
codegen-unitsflag.This reproduces with the latest nightly:
as well as the nightly immediately after the LLVM upgrade: