Skip to content

Send -fno-lto when linker plugin LTO is not requested to avoid having GCC do LTO when using rustc_codegen_gcc - #159924

Open
antoyo wants to merge 1 commit into
rust-lang:mainfrom
antoyo:fix/fno-lto
Open

Send -fno-lto when linker plugin LTO is not requested to avoid having GCC do LTO when using rustc_codegen_gcc#159924
antoyo wants to merge 1 commit into
rust-lang:mainfrom
antoyo:fix/fno-lto

Conversation

@antoyo

@antoyo antoyo commented Jul 25, 2026

Copy link
Copy Markdown
Contributor

More info on this Zulip thread.

cc @bjorn3

@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 25, 2026
@rustbot

rustbot commented Jul 25, 2026

Copy link
Copy Markdown
Collaborator

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 74 candidates
  • Random selection from 17 candidates

@bjorn3

bjorn3 commented Jul 25, 2026

Copy link
Copy Markdown
Member

Thinking about this again, this would cause a compilation failure if there is any C code compiled with -flto, right? Older versions of cc did that whenever rust LTO is enabled even though no LTO between C and Rust happens in that case. Only LTO between Rust crates and separately between C objects. And as it so happens rustc is currently stuck on said older version of the cc crate as disabling LTO for Jemalloc is a perf regression.

@antoyo

antoyo commented Jul 25, 2026

Copy link
Copy Markdown
Contributor Author

Thinking about this again, this would cause a compilation failure if there is any C code compiled with -flto, right?

You mean objects files that are not fat compiled with GCC?
Is this a case this is currently supported?
That would not work either when using LLD which is the default, no?
I would assume the way to support this would be to explicitly use a linker plugin.
What are your thoughts on this?

@bjorn3

bjorn3 commented Jul 25, 2026

Copy link
Copy Markdown
Member

That would not work either when using LLD which is the default, no?

It should currently work without extra configuration when using Clang as C compiler and either Clang as linker driver or LLD as linker though.

@antoyo

antoyo commented Jul 25, 2026

Copy link
Copy Markdown
Contributor Author

It should currently work without extra configuration when using Clang as C compiler and either Clang as linker driver or LLD as linker though.

So, we would need to only emit -fno-lto when gcc is used as the linker, right?
Is there a way to detect this?
If not, would using self.codegen_backend == "gcc" like we did in push_linker_plugin_lto_args be OK?

@fee1-dead

Copy link
Copy Markdown
Member

r? bjorn3

@rustbot rustbot assigned bjorn3 and unassigned fee1-dead Aug 1, 2026
@rust-log-analyzer

This comment has been minimized.

JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Sep 8, 2026
…r=Kobzol

Make `run-make` testsuite work with other codegen backend than LLVM

Needed for rust-lang#159924.

Currently, we always run `run-make` testsuite with the codegen backend rustc was compiled with. However, in CI it's compiled with LLVM, so when we want to test with GCC (with `--test-codegen-backend`), it compiles `rmake.rs` with the GCC backend, but when running the test, it doesn't use the GCC backend since it just calls `rustc`. So to get around that, I now pass the codegen backend through the environment and set it in the `rustc` function of `run_make_support`.

To be noted that for now it's only for the `rustc` function, no other command uses it. Should I extend it right away for all commands (well, likely only `cargo`) or just `rustc` for now is enough?

r? @jieyouxu
Zalathar added a commit to Zalathar/rust that referenced this pull request Sep 9, 2026
…r=Kobzol

Make `run-make` testsuite work with other codegen backend than LLVM

Needed for rust-lang#159924.

Currently, we always run `run-make` testsuite with the codegen backend rustc was compiled with. However, in CI it's compiled with LLVM, so when we want to test with GCC (with `--test-codegen-backend`), it compiles `rmake.rs` with the GCC backend, but when running the test, it doesn't use the GCC backend since it just calls `rustc`. So to get around that, I now pass the codegen backend through the environment and set it in the `rustc` function of `run_make_support`.

To be noted that for now it's only for the `rustc` function, no other command uses it. Should I extend it right away for all commands (well, likely only `cargo`) or just `rustc` for now is enough?

r? @jieyouxu
mu001999 added a commit to mu001999/rust that referenced this pull request Sep 9, 2026
…r=Kobzol

Make `run-make` testsuite work with other codegen backend than LLVM

Needed for rust-lang#159924.

Currently, we always run `run-make` testsuite with the codegen backend rustc was compiled with. However, in CI it's compiled with LLVM, so when we want to test with GCC (with `--test-codegen-backend`), it compiles `rmake.rs` with the GCC backend, but when running the test, it doesn't use the GCC backend since it just calls `rustc`. So to get around that, I now pass the codegen backend through the environment and set it in the `rustc` function of `run_make_support`.

To be noted that for now it's only for the `rustc` function, no other command uses it. Should I extend it right away for all commands (well, likely only `cargo`) or just `rustc` for now is enough?

r? @jieyouxu
rust-bors Bot pushed a commit that referenced this pull request Sep 9, 2026
Rollup merge of #162482 - GuillaumeGomez:run-make-backends, r=Kobzol

Make `run-make` testsuite work with other codegen backend than LLVM

Needed for #159924.

Currently, we always run `run-make` testsuite with the codegen backend rustc was compiled with. However, in CI it's compiled with LLVM, so when we want to test with GCC (with `--test-codegen-backend`), it compiles `rmake.rs` with the GCC backend, but when running the test, it doesn't use the GCC backend since it just calls `rustc`. So to get around that, I now pass the codegen backend through the environment and set it in the `rustc` function of `run_make_support`.

To be noted that for now it's only for the `rustc` function, no other command uses it. Should I extend it right away for all commands (well, likely only `cargo`) or just `rustc` for now is enough?

r? @jieyouxu
@GuillaumeGomez

Copy link
Copy Markdown
Member

#162482 got merged, so after a rebase, this PR should be ready to go.

@rustbot

rustbot commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@rust-log-analyzer

This comment has been minimized.

@@ -1,4 +1,5 @@
//@ ignore-cross-compile (need to run fake linker)
//@ ignore-backends: gcc

@antoyo antoyo Sep 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if there would be a way to make this test "generic" on whether the flag -fno-lto is present or not, but I guess it's not super important anyway.

View changes since the review

@antoyo

antoyo commented Sep 9, 2026

Copy link
Copy Markdown
Contributor Author

The test now passes.
@bjorn3: This is ready for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants