Move the libgccjit.so file in a target directory

[antoyo]

Since GCC is not multi-target, we need multiple libgccjit.so. Our solution to have a directory per target so that we can have multiple libgccjit.so.

r? @Kobzol

[rustbot]

This PR changes how GCC is built. Consider updating src/bootstrap/download-ci-gcc-stamp.

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[rustbot]

Kobzol is not on the review rotation at the moment.
They may take a while to respond.

[rustbot]

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

[antoyo]

@bjorn3: Is there any way to bless the UI tests for Aarch64 from an x86 computer?

[bjorn3]

You can try if ./x.py test tests/ui --target aarch64-unknown-linux-gnu --bless works.

[antoyo]

All these new test failures are due to the fact that --target is used and we now put libgccjit.so in a directory named after the target, so rustc_codegen_gcc doesn't find libgccjit.so.
Is this the correct way to ignore these tests?
Or are tests annotated with needs-llvm-compoments not expected to pass with a codegen that is not LLVM?

[bjorn3]

I think //@ ignore-backends: gcc makes sense. These tests would pass just fine with Cranelift if it is one of the targets supported by Cranelift. cg_clif always enables all backends of Cranelift.

[bors]

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

[bors]

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

[rustbot]

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.

[Kobzol]

The bootstrap changes look fine. I also understand why some tests might need reblessing. But I don't understand how this can break tests that worked previously with GCC? cg_gcc should work the same as before, right?

I tried it locally, but it panicked on this:

thread 'rustc' (168880) panicked at /projects/personal/rust/rust/compiler/rustc_codegen_ssa/src/mir/rvalue.rs:984:5:
assertion `left == right` failed
  left: __int8_t *
 right: void *
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed::<gccjit::types::Type, gccjit::types::Type>
   4: rustc_codegen_ssa::mir::rvalue::transmute_scalar::<rustc_codegen_gcc::builder::Builder>
   5: <rustc_codegen_ssa::mir::FunctionCx<rustc_codegen_gcc::builder::Builder>>::codegen_transmute_operand
   6: <rustc_codegen_ssa::mir::FunctionCx<rustc_codegen_gcc::builder::Builder>>::codegen_rvalue_operand
   7: rustc_codegen_ssa::mir::codegen_mir::<rustc_codegen_gcc::builder::Builder>
   8: rustc_codegen_ssa::base::codegen_instance::<rustc_codegen_gcc::builder::Builder>
   9: <rustc_middle::mir::mono::MonoItem as rustc_codegen_ssa::mono_item::MonoItemExt>::define::<rustc_codegen_gcc::builder::Builder>
  10: rustc_codegen_gcc::base::compile_codegen_unit::module_codegen
  11: rustc_codegen_gcc::base::compile_codegen_unit
  12: <rustc_codegen_gcc::GccCodegenBackend as rustc_codegen_ssa::traits::backend::ExtraBackendMethods>::compile_codegen_unit
  13: rustc_codegen_ssa::base::codegen_crate::<rustc_codegen_gcc::GccCodegenBackend>
  14: <rustc_codegen_gcc::GccCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  15: <rustc_session::session::Session>::time::<alloc::boxed::Box<dyn core::any::Any>, rustc_interface::passes::start_codegen::{closure#0}>
  16: rustc_interface::passes::start_codegen
  17: <rustc_interface::queries::Linker>::codegen_and_build_linker
  18: <std::thread::local::LocalKey<core::cell::Cell<*const ()>>>::with::<rustc_middle::ty::context::tls::enter_context<<rustc_middle::ty::context::GlobalCtxt>::enter<rustc_interface::passes::create_and_enter_global_ctxt<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>::{closure#2}::{closure#0}, core::option::Option<rustc_interface::queries::Linker>>::{closure#1}, core::option::Option<rustc_interface::queries::Linker>>::{closure#0}, core::option::Option<rustc_interface::queries::Linker>>
  19: <rustc_middle::ty::context::TyCtxt>::create_global_ctxt::<core::option::Option<rustc_interface::queries::Linker>, rustc_interface::passes::create_and_enter_global_ctxt<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>::{closure#2}::{closure#0}>
  20: <rustc_interface::passes::create_and_enter_global_ctxt<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>::{closure#2} as core::ops::function::FnOnce<(&rustc_session::session::Session, rustc_middle::ty::context::CurrentGcx, alloc::sync::Arc<rustc_data_structures::jobserver::Proxy>, &std::sync::once_lock::OnceLock<rustc_middle::ty::context::GlobalCtxt>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_middle::arena::Arena>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_hir::Arena>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2})>>::call_once::{shim:vtable#0}
  21: <alloc::boxed::Box<dyn for<'a> core::ops::function::FnOnce<(&'a rustc_session::session::Session, rustc_middle::ty::context::CurrentGcx, alloc::sync::Arc<rustc_data_structures::jobserver::Proxy>, &'a std::sync::once_lock::OnceLock<rustc_middle::ty::context::GlobalCtxt<'a>>, &'a rustc_data_structures::sync::worker_local::WorkerLocal<rustc_middle::arena::Arena<'a>>, &'a rustc_data_structures::sync::worker_local::WorkerLocal<rustc_hir::Arena<'a>>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}), Output = core::option::Option<rustc_interface::queries::Linker>>> as core::ops::function::FnOnce<(&rustc_session::session::Session, rustc_middle::ty::context::CurrentGcx, alloc::sync::Arc<rustc_data_structures::jobserver::Proxy>, &std::sync::once_lock::OnceLock<rustc_middle::ty::context::GlobalCtxt>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_middle::arena::Arena>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_hir::Arena>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2})>>::call_once
  22: rustc_interface::passes::create_and_enter_global_ctxt::<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>
  23: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::util::run_in_thread_with_globals<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<(), rustc_driver_impl::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}::{closure#0}, ()>
  24: rustc_span::create_session_globals_then::<(), rustc_interface::util::run_in_thread_with_globals<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<(), rustc_driver_impl::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}::{closure#0}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: please make sure that you have updated to the latest nightly

note: please attach the file at `/projects/personal/rust/rust/test-crate/hello/rustc-ice-2025-12-08T12_37_02-168862.txt` to your bug report

note: compiler flags: -Z codegen-backend=gcc

query stack during panic:
end of query stack

[antoyo]

I tried it locally, but it panicked on this:

This one is likely because you forgot to disable debug assertions.

The new tests failure are only caused because they specify a --target flag which makes this new code not find the libgccjit.so, since the directory for that target doesn't exist.

[Kobzol]

The new tests failure are only caused because they specify a --target flag which makes this new code not find the libgccjit.so, since the directory for that target doesn't exist.

I see. But before, cg_gcc definitely didn't have the corresponding libgccjit file for these targets. So it should have failed too, right? Just with a different error message. Why didn't the tests fail before? Were those silent failures?

[antoyo]

I see. But before, cg_gcc definitely didn't have the corresponding libgccjit file for these targets. So it should have failed too, right? Just with a different error message. Why didn't the tests fail before? Were those silent failures?

It would load the libgccjit.so for x86-64 and it seems most of these new tests failure are from error tests, so no compilation was actually done, so the wrong libgccjit.so doesn't matter here.
Is it possible that rustc calls the backend init() even when not generating code?

[Kobzol]

I see. Yeah, if it never got to the code generation stage, then it makes sense that it wouldn't fail before.

Is it possible that rustc calls the backend init() even when not generating code?

It seems to be called unconditionally right at the beginning of the compilation.

[Kobzol]

This looks reasonable. Let's see if it goes through full CI:

@bors r+ rollup=never

[bors]

📌 Commit 42059a3 has been approved by Kobzol

It is now in the queue for this repository.

[Zalathar]

Scheduling: If rollup #149796 fails, prefer a non-rolled-up PR to move on to while the failure is investigated.

@bors p=1

[bors]

⌛ Testing commit 42059a3 with merge a371038...

[bors]

☀️ Test successful - checks-actions
Approved by: Kobzol
Pushing a371038 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 0b96731 (parent) -> a371038 (this PR)

Test differences

Show 27 test diffs

Stage 2

• [mir-opt] tests/mir-opt/inline/inline_instruction_set.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/check-cfg/values-target-json.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/generics.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/infer.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/params-via-stack.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/return-via-stack.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/undeclared-lifetime.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/via-registers.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/wrong-abi-location-1.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-call/wrong-abi-location-2.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-entry/c-variadic.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-entry/generics.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-entry/infer.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-entry/params-via-stack.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/cmse-nonsecure/cmse-nonsecure-entry/return-via-stack.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/feature-gates/feature-gate-abi-msp430-interrupt.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/force-inlining/asm.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/issues/issue-37131.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/linkage-attr/raw-dylib/windows/unsupported-abi.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/print-request/supported-crate-types.rs#musl: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/print-request/supported-crate-types.rs#wasm: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/repr/repr_align_greater_usize.rs#aarch32: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/repr/repr_align_greater_usize.rs#msp430: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/target-feature/abi-incompatible-target-feature-attribute-fcw.rs: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/target-feature/feature-hierarchy.rs#aarch64-neon: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/target-feature/feature-hierarchy.rs#aarch64-sve2: pass -> ignore (gcc backend is marked as ignore) (J0)
• [ui] tests/ui/target-feature/no-llvm-leaks.rs#aarch64: pass -> ignore (gcc backend is marked as ignore) (J0)

Job group index

• J0: x86_64-gnu-gcc

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard a371038013f4f3e3f1d4fdcacfaa02c3252a518b --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. pr-check-2: 2184.2s -> 2624.3s (+20.1%)
2. x86_64-gnu-miri: 4095.5s -> 4912.9s (+20.0%)
3. x86_64-rust-for-linux: 2649.7s -> 3127.4s (+18.0%)
4. armhf-gnu: 4689.7s -> 5513.0s (+17.6%)
5. x86_64-gnu-llvm-20: 2312.2s -> 2671.0s (+15.5%)
6. x86_64-gnu-gcc: 2988.8s -> 3447.8s (+15.4%)
7. i686-gnu-2: 5570.2s -> 6325.4s (+13.6%)
8. x86_64-gnu-tools: 3187.6s -> 3577.5s (+12.2%)
9. i686-gnu-1: 7523.0s -> 8366.0s (+11.2%)
10. x86_64-mingw-1: 9425.1s -> 10433.4s (+10.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (a371038): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.7%, secondary 3.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.1%	[3.1%, 3.1%]	1
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.7%	[-2.7%, -2.7%]	1

Cycles

Results (primary 2.7%, secondary 6.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.7%	[2.7%, 2.7%]	1
Regressions ❌ (secondary)	6.7%	[6.7%, 6.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.7%	[2.7%, 2.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 471.709s -> 470.343s (-0.29%)
Artifact size: 389.01 MiB -> 389.02 MiB (0.00%)