SIGSEGV in LLVM FastISel::selectInstruction with codegen-units=1 on rustc 1.95.0

Code

This occurs on a real-world project (~15K lines Rust, heavy monomorphization from serde + rmcp + schemars + axum), not a minimal reproducer. I have not been able to isolate a minimal case — the crash is non-deterministic and hits different dependency crates on each run.

Configuration

# Cargo.toml
[profile.release]
opt-level = 1
codegen-units = 1

# .cargo/config.toml
[build]
jobs = 1
rustflags = ["-C", "debuginfo=1"]

Steps to reproduce

cargo clean
cargo test -p cynic-kernel --lib --release
# → SIGSEGV in a random dependency crate

Observed behavior

Release builds with codegen-units = 1 crash with SIGSEGV in LLVM's FastISel pass. The crashing crate is non-deterministic — a different crate crashes on each run:

Run	Crashing crate	Signal	LLVM function
1	yoke-derive	SIGSEGV	FastISel::selectInstruction
2	zerovec	SIGSEGV	FastISel::selectInstruction
3	regex-syntax	SIGSEGV	(backtrace not captured)
4	serde_json	SIGSEGV	(backtrace not captured)
5	tokio	SIGSEGV	LlvmCodegenBackend::optimize_thin

What does NOT help

Mitigation	Result
RUST_MIN_STACK=134217728 (128 MiB)	Still SIGSEGV (different crate)
RUST_MIN_STACK=268435456 (256 MiB)	Still SIGSEGV (different crate)
Removing -C debuginfo=1 from rustflags	Still SIGSEGV
cargo clean + fresh build	Still SIGSEGV

What fixes it

Mitigation	Result
codegen-units = 16 (default)	All 685 tests pass reliably
cargo check (no codegen)	Passes (235 crates)

Backtrace (run 1: yoke-derive)

error: rustc interrupted by SIGSEGV, printing backtrace

libLLVM.so.22.1(+0x48a35b4) — FastISel::selectInstruction
libLLVM.so.22.1 — SelectionDAGISel::SelectAllBasicBlocks
libLLVM.so.22.1 — SelectionDAGISel::runOnMachineFunction
libLLVM.so.22.1 — FPPassManager::runOnFunction
libLLVM.so.22.1 — FPPassManager::runOnModule
libLLVM.so.22.1 — legacy::PassManagerImpl::run
librustc_driver — LlvmCodegenBackend::codegen
librustc_driver — WriteBackendMethods::codegen

Backtrace (run 5: tokio — thin LTO path)

error: rustc interrupted by SIGSEGV, printing backtrace

librustc_driver — LlvmCodegenBackend::optimize_thin
librustc_driver — spawn_thin_lto_work

Additional: clippy ICE on incremental cache

Separately, clippy's redundant_clone lint crashes with SIGABRT when the incremental cache was built with codegen-units=1 and then the setting is changed:

thread 'rustc' panicked at compiler/rustc_middle/src/mir/syntax.rs:1197:23:
invalid enum variant tag while decoding `ProjectionElem`, expected 0..8, actual 221

And another incremental cache corruption:

thread 'rustc' panicked at compiler/rustc_middle/src/dep_graph/graph.rs:1413:32:
index out of bounds: the len is 1226193 but the index is 4243782

Both resolved by clearing target/debug/incremental/.

Analysis

The non-deterministic crate and LLVM backtrace suggest memory corruption within LLVM's codegen when constrained to a single codegen unit. With codegen-units=1, all monomorphized functions are emitted into a single LLVM module. This project has heavy monomorphization (serde + rmcp + schemars + axum) which may produce an unusually large single module that exposes a bug in LLVM 22.1.2's FastISel or thin LTO passes.

Meta

rustc --version --verbose:

rustc 1.95.0 (59807616e 2026-04-14)
binary: rustc
commit-hash: 59807616e1fa2540724bfbac14d7976d7e4a3860
commit-date: 2026-04-14
host: x86_64-unknown-linux-gnu
release: 1.95.0
LLVM version: 22.1.2

OS: Linux 6.17.0-23-generic (Ubuntu 24.04), x86_64
RAM: 28 GiB (8-10 GiB available at time of crashes)

Possibly related

• #103767 (LLVM stack overflow on deep monomorphization)
• #122357 (SIGSEGV in codegen)
• #138561 (LLVM SROA bug)

Start by reproducing the failure with cargo test -p cynic-kernel --lib --release using codegen-units = 1, then compare it with the reliable codegen-units = 16 build. Read the reported FastISel::selectInstruction, LlvmCodegenBackend::optimize_thin, and rustc_middle panic locations. Done means identifying a minimal reproducer or a confirmed compiler/LLVM or incremental-cache cause with a targeted regression test.