Skip to content

LTO=thin appears broken on nightly rustc? #110256

Closed
@allight

Description

@allight

When building https://github.com/alacritty/alacritty with cargo build -r on nightly rust the resulting binary will segfault. This does not occur when built with stable rust.

This behavior change appears to be gated by lto="thin".

Code

I tried this code:

rustup default nightly
rustup update
git clone https://github.com/alacritty/alacritty
cd alacritty
cargo build -r
./target/release/alacritty

I expected to see this happen: alacritty to startup as occurs with rustup default stable

Instead, this happened: compiled program segfaults

Version it worked on

stable-x86_64-unknown-linux-gnu unchanged - rustc 1.68.2 (9eb3afe 2023-03-27)

Version with regression

nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.70.0-nightly (9df3a39 2023-04-11)

rustc --version --verbose:

rustc 1.70.0-nightly (9df3a39fb 2023-04-11)
binary: rustc
commit-hash: 9df3a39fb30575d808e70800f9fad5362aac57a2
commit-date: 2023-04-11
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.2

This appears to be triggered by lto being set to "thin" in Cargo.toml

See alacritty issues: alacritty/alacritty#6818 and alacritty/alacritty#6854 for investigation.

Metadata

Metadata

Assignees

Labels

A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleI-unsoundIssue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/SoundnessP-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-untriagedUntriaged performance or correctness regression.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions