[ICE]: LLVM ERROR "Broken module" with -C target-cpu=native on aarch64-apple-darwin (Apple M5, LLVM 22.1.0) #153397
Description
Code
Any crate with sufficient code triggers this. Minimal reproducer using aho-corasick:
cargo new --lib repro && cd repro
sed -i '' 's/\[dependencies\]/[dependencies]\naho-corasick = "1.1.4"/' Cargo.toml
echo 'pub fn f() { let _ = aho_corasick::AhoCorasick::new(["hello"]).unwrap(); }' > src/lib.rs
RUSTFLAGS="-C target-cpu=native" cargo +nightly buildFails at opt-level >= 1. Works at opt-level = 0.
Meta
rustc --version --verbose:
rustc 1.96.0-nightly (d9563937f 2026-03-03)
binary: rustc
commit-hash: d9563937fa3b030c5845811113505070109414d2
commit-date: 2026-03-03
host: aarch64-apple-darwin
release: 1.96.0-nightly
LLVM version: 22.1.0
Hardware: Apple M5 (detected by LLVM as apple-m4 — LLVM does not yet know M5).
Error output
target-features attribute should not contain an empty string
target-features attribute should not contain an empty string
target-features attribute should not contain an empty string
target-features attribute should not contain an empty string
rustc-LLVM ERROR: Broken module found, compilation aborted!
error: could not compile `aho-corasick` (lib)
Caused by:
process didn't exit successfully: `rustc --crate-name aho_corasick ... -C target-cpu=native` (exit status: 101)
Analysis
-C target-cpu=native resolves to apple-m4 on this Apple M5 host. At opt-level >= 1, LLVM generates IR with an empty entry in the target-features function attribute (e.g. "+feat1,,+feat2"). The LLVM 22 IR Verifier rejects this with "target-features attribute should not contain an empty string" and aborts.
At opt-level = 0 the same code compiles successfully. Stable Rust (1.85.1, LLVM 19) also works fine with the same flags.
The root cause is likely in how rustc or LLVM 22 constructs the target-features string for the apple-m4 CPU definition — an empty feature name is being included in the comma-separated list.
Bisection notes
Not yet bisected. The bug is present on nightly 2026-03-03 (LLVM 22.1.0) and absent on stable 1.85.1 (LLVM 19). Likely introduced with the LLVM 22 upgrade.