Allow running tests with GCC #144687

GuillaumeGomez · 2025-07-30T15:03:04Z

This PR does two things:

Allow to build rustc with GCC (first commit)
Allow to run tests with the GCC backend (second commit)

However, if you try it out, compilation will fail, hence why I didn't update the CI yet. We have a sync in progress to fix these bugs. If you want to try it, you can use this branch which includes commits from the current cg_gcc sync.

r? @Kobzol

rustbot · 2025-07-30T15:03:11Z

Some changes occurred in src/tools/compiletest

cc @jieyouxu

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

GuillaumeGomez · 2025-07-30T15:05:46Z

src/bootstrap/src/core/build_steps/test.rs

@@ -1769,7 +1769,10 @@ NOTE: if you're sure you want to do this, please open an issue as to why. In the
        cmd.arg("--host").arg(&*compiler.host.triple);
        cmd.arg("--llvm-filecheck").arg(builder.llvm_filecheck(builder.config.host_target));

-        if let Some(codegen_backend) = builder.config.default_codegen_backend(compiler.host) {
+        if let Some(codegen_backend) = builder.config.codegen_backends(compiler.host).first() {


Since we don't seem to run commands for each registered backend, I simply look at the first for now. Should I add a FIXME comment on it?

I don't understand this change, why didn't you just use default_codegen_backend? It does the same thing (looks at the first codegen backend).

default_codegen_backend() is literally implemented as codegen_backends().first().
Edit: for some reason github didn't show me Kobzol's comment before.

I just submitted it now 😆 It was a pending comment, but GH uses the original time when it was written, not when it was submitted, which is a bit confusing.

GuillaumeGomez · 2025-07-30T15:05:52Z

src/bootstrap/src/core/build_steps/test.rs

@@ -1917,6 +1920,11 @@ NOTE: if you're sure you want to do this, please open an issue as to why. In the
            cmd.arg(exclude);
        }

+        if builder.config.codegen_backends(target).first().map(|b| b.as_str()) == Some("gcc") {


GuillaumeGomez · 2025-07-30T15:06:00Z

src/bootstrap/src/core/builder/cargo.rs

@@ -563,6 +563,12 @@ impl Builder<'_> {
            println!("using sysroot {sysroot_str}");
        }

+        if self.config.codegen_backends(target).first().map(|b| b.as_str()) == Some("gcc") {


GuillaumeGomez · 2025-07-30T15:06:39Z

src/bootstrap/src/core/config/config.rs

@@ -1226,6 +1226,13 @@ impl Config {
        self.out.join(self.host_target).join("ci-rustc")
    }

+    pub(crate) fn libgccjit_root(&self) -> PathBuf {


Considering we don't store GCC in the same ___location depending whether we build it or we download it, I found it better to handle it in one place instead, hence the creation of this method.

antoyo · 2025-07-30T17:12:09Z

src/bootstrap/src/core/builder/cargo.rs

+        if self.config.codegen_backends(target).first().map(|b| b.as_str()) == Some("gcc") {
+            let gcc_sysroot = self.config.libgccjit_root();
+            let gcc_sysroot = gcc_sysroot.as_os_str().to_str().expect("sysroot should be UTF-8");
+            cargo.env("LD_LIBRARY_PATH", gcc_sysroot);


How is it done for cg_llvm?
Couldn't we reuse what is done there?

Why isn't libgccjit copied into the sysroot like for libLLVM?

Excellent question, absolutely no clue.

That works for build, but not for dist, we do not want to dist libgccjit.so by default with rustup (at least not yet). If build did this automatically, we would have to explicitly skip it when creating the dist archives (normally we mostly copy all .so files to them, I think).

Dist has an explicit list of files to include in each component, right? It has to for each .so files to not end up in every component. So the cg_gcc component can include just cg_gcc.so and not libgccjit.so.

I don't think it's very explicit in this case:

rust/src/bootstrap/src/core/build_steps/dist.rs

Line 451 in e9c9b03

let libdir = builder.rustc_libdir(compiler);

To clarify, the cg_gcc rustup component should include both cg_gcc.so and libgccjit.so. But the normal rustc component shouldn't contain libgccjit.so.

bjorn3 · 2025-07-31T10:54:46Z

src/tools/compiletest/src/runtest.rs

+        if !matches!(self.config.codegen_backend, crate::CodegenBackend::Llvm) {
+            let lib_path = self.config.sysroot_base.join(self.config.codegen_backend.as_str());
+            rustc.arg(format!("-Zcodegen-backend={}", lib_path));
+        }


This always matches the default codegen backend, right? In that case no explicit -Zcodegen-backend should be necessary.

Kobzol · 2025-07-31T11:28:57Z

I looked at how the backends are configured today and I think that before we go forward with enabling the tests, we should first both clean the handling of the backends, and understand/decide how will the GCC lookup work in practice. Some work items:

Stop treating codegen backends as strings (Create a typed wrapper for codegen backends in bootstrap #144730)
x build rustc_codegen_gcc currently builds stage 2 rustc, that is wrong, so the staging seems to be broken there. This is blocked on Consolidate staging for rustc_private tools #144303.

Regarding the GCC lookup, we need to figure out a universal way of how will cg_gcc find libgccjit.so. Spamming libdir paths at all the tests that could possibly use the GCC backend is not very scalable, and won't work for using the GCC backend outside bootstrap. When I x build rustc_codegen_gcc, the resulting stage1 sysroot doesn't work with RUSTFLAGS="-Zcodegen-backend=gcc" cargo +stage1 build, because it can't find libgccjit.so. This should "just work", if it did, we don't need to do additional bootstrap magic.

GuillaumeGomez · 2025-07-31T13:42:09Z

I can link the .so files in a given ___location. Question is: where?

Kobzol · 2025-07-31T19:04:05Z

I suspect that the most straightforward solution would be to do what LLVM does, so either put it in the lib sysroot or use rpath. But we have to be careful around dist, so that we don't accidentally ship the GCC stuff in our distribution archives. It shouldn't be that hard though, as we won't enable GCC on dist builders for the main compiler toolchain yet.

I checked that if we put libgccjit.so in the lib sysroot, and then pass -Zcodegen-backend=gcc to rustc, it works correctly. So putting libgccjit.so into the sysroot if GCC is configured as the default codegen backend is probably a good start. We should do this in the Assemble step.

bors · 2025-08-01T14:59:17Z

☔ The latest upstream changes (presumably #144773) made this pull request unmergeable. Please resolve the merge conflicts.

GuillaumeGomez · 2025-08-01T15:15:41Z

Gonna do that then.

Kobzol · 2025-08-01T15:16:35Z

Note that I'm currently refactoring the codegen backends quite a lot. So if you don't mind, I'd try to prepare this once that refactoring is done.

GuillaumeGomez · 2025-08-01T15:19:28Z

Even the Assemble phase? If so, please ping me so I can do it once you're done. ;)

Kobzol · 2025-08-01T15:35:33Z

Yeah, that too a little bit.

Allow to compile rustc with GCC as backend

ba3a448

rustbot assigned Kobzol Jul 30, 2025

GuillaumeGomez commented Jul 30, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

Fix compiletest run when using GCC as backend

5a1a756

GuillaumeGomez force-pushed the tests-with-gcc branch from 29d84ca to 5a1a756 Compare July 30, 2025 15:28

antoyo reviewed Jul 30, 2025

View reviewed changes

bjorn3 reviewed Jul 31, 2025

View reviewed changes

Allow running tests with GCC #144687

Are you sure you want to change the base?

Allow running tests with GCC #144687

Uh oh!

Conversation

GuillaumeGomez commented Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kobzol commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeGomez commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kobzol commented Jul 31, 2025

Uh oh!

bors commented Aug 1, 2025

Uh oh!

GuillaumeGomez commented Aug 1, 2025

Uh oh!

Kobzol commented Aug 1, 2025

Uh oh!

GuillaumeGomez commented Aug 1, 2025

Uh oh!

Kobzol commented Aug 1, 2025

Uh oh!

Uh oh!

GuillaumeGomez commented Jul 30, 2025 •

edited

Loading

bjorn3 Jul 31, 2025 •

edited

Loading

bjorn3 Jul 31, 2025 •

edited

Loading

Kobzol commented Jul 31, 2025 •

edited

Loading

GuillaumeGomez commented Jul 31, 2025 •

edited

Loading