Send -fno-lto when linker plugin LTO is not requested to avoid having GCC do LTO when using rustc_codegen_gcc by antoyo · Pull Request #159924 · rust-lang/rust

antoyo · 2026-07-25T19:10:56Z

rustbot · 2026-07-25T19:11:00Z

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 · 2026-07-25T19:57:33Z

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 · 2026-07-25T20:14:44Z

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 · 2026-07-25T20:43:40Z

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 · 2026-07-25T20:52:05Z

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 · 2026-08-01T17:18:29Z

r? bjorn3

@jieyouxu

…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

@jieyouxu

…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

@jieyouxu

…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

@jieyouxu

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 · 2026-09-09T09:52:16Z

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

antoyo · 2026-09-09T18:55:59Z

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

mati865 · 2026-09-22T19:25:04Z

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

Yes.

You mean objects files that are not fat compiled with GCC?
Is this a case this is currently supported?

This is the default mode for GCC/Clang and it should work as long as you don't explicitly pass -fno-lto. Fat objects require additional argument to be produced: -ffat-lto-objects.

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

No, LLD doesn't handle GIMPLE bitcode at all (it doesn't even support the plugins).
I'm not sure if LLD is even a good default for GCC backend.

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

Only when the host Clang version that produced the objects matches LLD version (by default the one shipped with particular Rust version). Also, when using Clang + any linker other than LLD -flto must be provided, otherwise Clang won't add linker plugin.
Since GCC is typically "the default" C/C++ compiler on Linux, in the great majority of the cases this won't work right now.

So, we would need to only emit -fno-lto when gcc is used as the linker, right?

For Clang it will make no difference since (-no)-flto only affects whether the compiler passes the plugin. So, we have:

GCC/Clang + LLD - (-no)-flto makes no difference as linker plugins are not used by LLD
GCC + non-LLD - implicit GCC LTO plugin can be disabled with -no-flto
Clang + non-LLD - no implicit plugin, -no-flto has no effect

Codegen options will likely need to be updated to reflect that: https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-plugin-lto

One thing here I'm failing to understand is why should GCC backend differ from LLVM one here. Since libstd produced by LLVM backend is a fat object, LLD probably does some kind of LTO on it?

antoyo · 2026-09-22T21:00:19Z

One thing here I'm failing to understand is why should GCC backend differ from LLVM one here.

GCC needs additional files to do LTO (libgccjit.so is not enough) which are not distributed/built in the Rust repo (neither by rustup).

Also, is cg_llvm really automatically doing LTO when building a program that depends on the std because the std is a fat object (even when not asked by the user)?
I'm asking because another reason I wanted this -fno-lto flag being passed is that it makes the compilation time of a simple "Hello, world!" program compiled by cg_gcc go to 30 seconds/1 minute.

antoyo · 2026-09-22T22:10:44Z

As I understand it, in the LLVM world the embedded bitcode of fat objects is ignored by the linker unless -flto is passed to clang.

Even for Rust? I thought you said otherwise above in this thread.

mati865 · 2026-09-23T11:25:29Z

Okay, those are pretty compelling arguments for disabling plugin based LTO with GCC backend.

I made small experiment with C code and LLD will only use bitcode from fat objects if given --ffat-lto-objects, which aligns with its --help. So, only when Clang was called with -flto -ffat-lto-objects.

With Rust the situation might be different because Clang puts bitcode in .llvm.lto, whereas rustc puts it in .llvmbc.

bjorn3 · 2026-09-23T11:34:36Z

With Rust the situation might be different because Clang puts bitcode in .llvm.lto, whereas rustc puts it in .llvmbc.

According to https://llvm.org/docs/BitCodeFormat.html#native-object-file-wrapper-format .llvmbc can also be produced by LLVM, but turns out the linker plugin will indeed ignore it. If I understand correctly that would mean -Clinker-plugin-lto would be ignoring the standard library entirely. cc @nikic

antoyo · 2026-09-23T13:22:31Z

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

Just to make sure I understand, this is not actually the case? Would using clang without -Clinker-plugin-lto do any LTO at all when there are fat objects?

bjorn3 · 2026-09-23T13:30:51Z

I would have expected it to do LTO for C code that is compiled with -flto but without -ffat-lto-objects. I just checked it and it is the case when lld is used, not when any other linker is used with clang.

; echo 'int main() { return 0; }' | clang -flto -x c -c - -o foo.o
; clang foo.o -o foo
foo.o: file not recognized: file format not recognized
clang: error: linker command failed with exit code 1 (use -v to see invocation)
; clang foo.o -o foo -flto
; clang foo.o -o foo -fuse-ld=lld
; ./foo

antoyo · 2026-09-23T13:54:55Z

I would have expected it to do LTO for C code that is compiled with -flto but without -ffat-lto-objects.

But does Rust send -flto to clang by default?
The difference here is that GCC (used as the linker, when sent object files) will do LTO even without -flto if some object files contain the GCC IR.

bjorn3 · 2026-09-23T14:10:22Z

But does Rust send -flto to clang by default?

No, only when using -Clinker-plugin-lto.

The difference here is that GCC (used as the linker, when sent object files) will do LTO even without -flto if some object files contain the GCC IR.

lld does do LTO without -flto when object files only contain bitcode (but not for -ffat-lto-objects). Clang doesn't for other linkers though.

antoyo · 2026-09-24T15:52:46Z

Is there anything we should change in this PR or is it good to merge?

bjorn3 · 2026-10-02T12:07:26Z

I'm not convinced this is indeed what we should do. Happy to approve after #159924 (comment)

antoyo · 2026-10-02T12:12:22Z

I'm not convinced this is indeed what we should do.

Do you think that because of the issue you've just opened?
It seems there might be some differences between gcc and clang for whether they automatically do LTO or not: do you think we'll be able to make that work in rustc without the hack in this PR?

I can wait a bit before merging this PR in case we find a better general solution.

bjorn3 · 2026-10-02T12:18:32Z

s/not/now 🤦 I think if we fully fix linker plugin LTO (both the trivial case I opened an issue for and including the standard library), we may also need to pass -fno-lto on LLVM in the future.

rustbot · 2026-10-02T12:28:23Z

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.

… GCC do LTO when using rustc_codegen_gcc

bjorn3 · 2026-10-02T15:24:16Z

@bors r+

rust-bors · 2026-10-02T15:24:20Z

📌 Commit 4613f38 has been approved by bjorn3

It is now in the queue for this repository.

…uwer Rollup of 9 pull requests Successful merges: - #163655 (explicitly handle tests that pass with -Znext-solver) - #159924 (Send -fno-lto when linker plugin LTO is not requested to avoid having GCC do LTO when using rustc_codegen_gcc) - #163572 (Update the minimum external LLVM to 22) - #129822 (Docs - type guarantees update) - #157973 (Distinguish `repr(C)` ZSTs from others in ABI compatibility rules) - #162332 (preserve overflow in builtin Field candidates) - #163574 (intrinsics: Rename `abort` to `abort_immediate`) - #163638 (avoid trivial `fn map_bound` validations) - #163660 (yeet compare-mode-coherence)

@bjorn3

Rollup merge of #159924 - antoyo:fix/fno-lto, r=bjorn3 Send -fno-lto when linker plugin LTO is not requested to avoid having GCC do LTO when using rustc_codegen_gcc More info on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Add.20linker.20flag.20from.20the.20codegen/near/375045533). cc @bjorn3

rustbot assigned fee1-dead Jul 25, 2026

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

antoyo force-pushed the fix/fno-lto branch from a4242c7 to c1af4ca Compare July 25, 2026 19:17

antoyo force-pushed the fix/fno-lto branch from c1af4ca to c553de8 Compare July 25, 2026 20:41

rustbot assigned bjorn3 and unassigned fee1-dead Aug 1, 2026

antoyo force-pushed the fix/fno-lto branch from c553de8 to 4de67b9 Compare August 11, 2026 14:22

This comment has been minimized.

Sign in to view

GuillaumeGomez mentioned this pull request Sep 8, 2026

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

Merged

antoyo force-pushed the fix/fno-lto branch from 4de67b9 to f44c5df Compare September 9, 2026 15:13

This comment has been minimized.

Sign in to view

antoyo force-pushed the fix/fno-lto branch from f44c5df to 6a9b179 Compare September 9, 2026 16:16

antoyo commented Sep 9, 2026

View reviewed changes

Comment thread tests/run-make/linker-warning/rmake.rs Outdated

bjorn3 mentioned this pull request Oct 2, 2026

Linker plugin LTO broken? #163652

Open

bjorn3 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 2, 2026

antoyo force-pushed the fix/fno-lto branch from 6a9b179 to 8c5fdaf Compare October 2, 2026 12:28

This comment has been minimized.

Sign in to view

Send -fno-lto when linker plugin LTO is not requested to avoid having…

4613f38

… GCC do LTO when using rustc_codegen_gcc

antoyo force-pushed the fix/fno-lto branch from 8c5fdaf to 4613f38 Compare October 2, 2026 13:49

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 2, 2026

JonathanBrouwer mentioned this pull request Oct 2, 2026

Rollup of 9 pull requests #163680

Merged

rust-bors Bot merged commit adb1584 into rust-lang:main Oct 3, 2026
14 checks passed

rustbot added this to the 1.101.0 milestone Oct 3, 2026

github-actions Bot mentioned this pull request Oct 4, 2026

Toolchain upgrade to nightly-2026-10-04 flux-rs/flux#1811

Draft

Uh oh!

Conversation

antoyo commented Jul 25, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 25, 2026

Uh oh!

bjorn3 commented Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antoyo commented Jul 25, 2026

Uh oh!

bjorn3 commented Jul 25, 2026

Uh oh!

antoyo commented Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fee1-dead commented Aug 1, 2026

Uh oh!

This comment has been minimized.

GuillaumeGomez commented Sep 9, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

antoyo commented Sep 9, 2026

Uh oh!

mati865 commented Sep 22, 2026

Uh oh!

antoyo commented Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antoyo commented Sep 22, 2026

Uh oh!

mati865 commented Sep 23, 2026

Uh oh!

bjorn3 commented Sep 23, 2026

Uh oh!

antoyo commented Sep 23, 2026

Uh oh!

bjorn3 commented Sep 23, 2026

Uh oh!

antoyo commented Sep 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bjorn3 commented Sep 23, 2026

Uh oh!

antoyo commented Sep 24, 2026

Uh oh!

bjorn3 commented Oct 2, 2026

Uh oh!

antoyo commented Oct 2, 2026

Uh oh!

bjorn3 commented Oct 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 2, 2026

Uh oh!

This comment has been minimized.

bjorn3 commented Oct 2, 2026

Uh oh!

rust-bors Bot commented Oct 2, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

antoyo commented Jul 25, 2026 •

edited by rustbot

Loading

bjorn3 commented Jul 25, 2026 •

edited

Loading

antoyo commented Jul 25, 2026 •

edited

Loading

antoyo commented Sep 22, 2026 •

edited

Loading

antoyo commented Sep 23, 2026 •

edited

Loading

bjorn3 commented Oct 2, 2026 •

edited

Loading