Linker-plugin-based LTO with -flto in clang not working

The original issue title was "Implement cross-language ThinLTO," #49879 but when it was stabilized, the PR title became "Stabilize linker-plugin based LTO (aka cross-language LTO)," #58057 which seems to imply that fullLTO is available. The Rustc book states, "In both cases the Rust code has to be compiled with -C linker-plugin-lto and the C/C++ code with -flto or -flto=thin so that object files are emitted as LLVM bitcode," https://doc.rust-lang.org/rustc/linker-plugin-lto.html which also seems to confirm this. However, the documentation does not provide an example of fullLTO, and simply replacing "-flto=thin" with "-flto" does not work. Therefore, this should be considered a bug.

// with clang -flto=thin
// works
000000000005e054 <c_func_in_rust>:
   5e054:	52800540 	mov	w0, #0x2a                  	// #42
   5e058:	d65f03c0 	ret

// with clang -flto
// doesn't work
000000000005e09c <c_func_in_rust>:
   5e09c:	17ffffd9 	b	5e000 <c_func_in_c>

000000000005e000 <c_func_in_c>:
   5e000:	52800540 	mov	w0, #0x2a                  	// #42
   5e004:	d65f03c0 	ret

$ rustc --version --verbose
rustc 1.85.1 (4eb161250 2025-03-15)
binary: rustc
commit-hash: 4eb161250e340c8f48f66e2b929ef4a5bed7c181
commit-date: 2025-03-15
host: aarch64-unknown-linux-gnu
release: 1.85.1
LLVM version: 19.1.7

# build.sh
# copied from https://doc.rust-lang.org/rustc/linker-plugin-lto.html
clang ./clib.c -flto=thin -c -o ./clib.o -O2
#                   ^^^^^ remove this and it will not work
ar crus ./libxyz.a ./clib.o
RUSTFLAGS="-Clinker-plugin-lto -Clinker=clang -Clink-arg=-fuse-ld=lld" cargo build --release
objdump -d target/release/x > dump

// main.rs
use std::ffi::c_int;

fn main() {
    println!("{}", c_func_in_rust());
}

#[inline(never)]
#[unsafe(no_mangle)]
pub extern "C" fn c_func_in_rust() -> c_int {
    unsafe { c_func_in_c() }
}

unsafe extern "C" {
    fn c_func_in_c() -> c_int;
}

// build.rs
fn main() {
    println!("cargo:rerun-if-changed=build.rs");
    println!("cargo:rustc-link-search=.");
    println!("cargo:rustc-link-lib=xyz")
}

// clib.c
int c_func_in_c() {
    return 42;
}

# Cargo.toml
[package]
name = "x"
version = "0.1.0"
edition = "2024"

x
├── build.rs
├── build.sh
├── Cargo.toml
├── clib.c
└── src
    └── main.rs

[dianqk]

#136840 (comment) should fix this.

[zamazan4ik]

@dianqk Seems like the issue should be resolved with Rustc 1.90 (according to the information from 7a127fb since it has 1.90 git tag). However, I've tested the example above with Rustc 1.90 - the situation remains the same: with FullLTO we still get the same result with both functions.

Env: x86-64 arch, Fedora 42, Rustc 1.90, Clang 20.1.8 (the latest from Fedora repos)

[foxtran]

I've tested linker-plugin-based LTO with some setup (see below) and it does not work with -flto=full. And used compiler still lacks full support of -lto=thin. Briefly, I still see the described issue with nigthly Rust compiler.

Compilation of Fortran part (with some scientific code computing arg**(4/3)):

flang -O3 -flto test.f90 -c -o test.f90.o

Note: -flto=thin is not fully supported yet for Fortran compiler

Creating archive:

ar crus ./libDFT.a ./test.f90.o

Compiling Rust binary:

rustc -Clinker-plugin-lto -L. -lDFT -Copt-level=3 -Clinker=clang -Clink-arg=-fuse-ld=lld ./main.rs

Then, in binary, I see only unrolled calls:

000000000005b500 <slater>:
   5b56a:	67 e8 90 ff ff ff    	addr32 call 5b500 <slater>
   5b5f5:	67 e8 05 ff ff ff    	addr32 call 5b500 <slater>
   5b65c:	67 e8 9e fe ff ff    	addr32 call 5b500 <slater>

and only single pow (I've expected three of them):

   5b509:	e8 a2 02 00 00       	call   5b7b0 <pow@plt>
000000000005b7b0 <pow@plt>:

I've used the following combination:

rust compiler:

$ rustc -Vv
rustc 1.92.0-nightly (dd7fda570 2025-09-20)
binary: rustc
commit-hash: dd7fda570040e8a736f7d8bc28ddd1b444aabc82
commit-date: 2025-09-20
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.1

flang compiler:

$ flang --version
flang version 21.1.1 (https://github.com/llvm/llvm-project.git 5a86dc996c26299de63effc927075dcbfb924167)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /somewhere/rust/.llvm-bin/bin

[zamazan4ik]

Still reproducible with Rustc 1.93 (rustc 1.93.0 (254b59607 2026-01-19)) and Clang 21.1.8 (clang version 21.1.8 (Fedora 21.1.8-3.fc43)).

[foxtran]

The problem is that no one passed -Clto to rustc, so, it generated bytecode which seems to be incompatible with fat-LTO. More specifically, llvm.module has the following flags if only -Clinker-plugin-lto is passed:

!llvm.module.flags = !{!0, ...}
!0 = !{i32 1, !"ThinLTO", i32 1}

I.e. compiled with thin-LTO.

With -Clto is is changing to:

!llvm.module.flags = !{!0, ...}
!0 = !{i32 1, !"ThinLTO", i32 0}

ThinLTO is disabled.

I have retested it with flang. The source code:

! cat lda.f90
real function lda_x_exc(rho) bind(C, name="lda_x_exc")
  implicit none
  real, value, intent(in) :: rho
  real t1, t2, t3
  t1 = rho ** (1. / 3.)
  t2 = t1 * t1
  t3 = t2 * t2
  lda_x_exc = -0.76 * t3
end function lda_x_exc

// cat main.rs
extern "C" {
    fn lda_x_exc(val: f32) -> f32;
}

fn main() {
    let inputs = [1.0f32, 2.0, 3.0];
    let mut outputs = [0.0f32; 3];

    unsafe {
        for i in 0..3 {
            outputs[i] = lda_x_exc(inputs[i]);
        }
    }
    println!("{:?}", outputs);
}

Commands to run:

flang -flto -O3 lda.f90 -c -o lda.f90.o
ar crus ./libDFT.a ./lda.f90.o
rustc -Clinker-plugin-lto -L. -lDFT -Copt-level=3 -Clinker=clang -Clink-arg=-fuse-ld=lld ./main.rs -o main-thin
rustc -Clinker-plugin-lto -Clto -L. -lDFT -Copt-level=3 -Clinker=clang -Clink-arg=-fuse-ld=lld ./main.rs -o main-full
objdump -S main-thin > main-thin.S
objdump -S main-full > main-full.S

Checking powf call:

$ rg "powf" *.S
main-thin.S
76183:   5b969:	e8 72 02 00 00       	call   5bbe0 <powf@plt>
76493:000000000005bbe0 <powf@plt>:
76494:   5bbe0:	ff 25 6a 49 00 00    	jmp    *0x496a(%rip)        # 60550 <powf@GLIBC_2.27>

No powf calls in main-full.S since everything was compiled at compile-time. So, full-LTO works only with if one passes -Clto to rustc.

This behaviour should be documented :-)

[eggyal]

This behaviour should be documented :-)

You mean like the documentation for -Clto ? 😉

If -C lto is not specified, then the compiler will attempt to perform "thin local LTO" which performs "thin" LTO on the local crate only across its codegen units. When -C lto is not specified, LTO is disabled if codegen units is 1 or optimizations are disabled (-C opt-level=0). That is:

• When -C lto is not specified:
  • codegen-units=1: disable LTO.
  • opt-level=0: disable LTO.
• When -C lto is specified:
  • lto: 16 codegen units, perform fat LTO across crates.
  • codegen-units=1 + lto: 1 codegen unit, fat LTO across crates.

See also embed-bitcode and linker-plugin-lto.

[foxtran]

Documented in #151933

I'm open to suggestions.