Skip to content

GCC backend subtree update #143239

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 55 commits into from
Jun 30, 2025

Conversation

GuillaumeGomez
Copy link
Member

cc @antoyo

r? ghost

bjorn3 and others added 30 commits June 3, 2025 10:00
It is only used within cg_llvm.
It is only used within cg_llvm.
And move passing it to the linker to the driver code.
This deduplicates some code between codegen backends and may in the
future allow adding extra metadata that is only known at link time.
…=bjorn3

Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi`

Our `conv_from_spec_abi`, `adjust_abi`, and `is_abi_supported` combine to give us a very confusing way of reasoning about what _actual_ calling convention we want to lower our code to and whether we want to compile the resulting code at all. Instead of leaving this code as a miniature adventure game in which someone tries to combine stateful mutations into a Rube Goldberg machine that will let them escape the maze and arrive at the promised land of codegen, we let `AbiMap` devour this complexity. Once you have an `AbiMap`, you can answer which `ExternAbi`s will lower to what `CanonAbi`s (and whether they will lower at all).

Removed:
- `conv_from_spec_abi` replaced by `AbiMap::canonize_abi`
- `adjust_abi` replaced by same
- `Conv::PreserveAll` as unused
- `Conv::Cold` as unused
- `enum Conv` replaced by `enum CanonAbi`

target-spec.json changes:
- If you have a target-spec.json then now your "entry-abi" key will be specified in terms of one of the `"{abi}"` strings Rust recognizes, e.g.
```json
    "entry-abi": "C",
    "entry-abi": "win64",
    "entry-abi": "aapcs",
```
Many of `std`'s dependency have a dependency on the crates.io
`compiler-builtins` when used with the feature
`rustc-std-workspace-core`. Use a Cargo patch to select the in-tree
version instead.

`compiler-builtins` is also added as a dependency of
`rustc-std-workspace-core` so these crates can remove their crates.io
dependency in the future.
… r=workingjubilee

store `target.min_global_align` as an `Align`

Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
…ieyouxu

Remove all unused feature gates from the compiler
…jorn3

Use the in-tree `compiler-builtins` for the sysroot

Many of `std`'s dependency have a dependency on the crates.io `compiler-builtins` when used with the feature `rustc-std-workspace-core`. Use a Cargo patch to select the in-tree version instead.

`compiler-builtins` is also added as a dependency of `rustc-std-workspace-core` so these crates can remove their crates.io dependency in the future.

Zulip discussion: [#t-compiler > Using in-tree compiler-builtins](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Using.20in-tree.20compiler-builtins/with/522445336)

Once this merges, the following PRs will need to make it to a release for the relevant crates:

- rust-lang/getopts#119 (can merge at any time)
- rust-lang/hashbrown#625 (can merge at any time)
- rust-lang/stdarch#1825
- rust-lang/rustc-demangle#80
- rust-lang/cfg-if#84
- unicode-rs/unicode-width#77

The above should cover all tier 1 targets with no `std` features enabled. The remaining cover the rest:

- alexcrichton/dlmalloc-rs#50 (wasm, xous, sgx)
- gimli-rs/gimli#769
- r-efi/r-efi#89 (efi)
- r-efi/r-efi-alloc#9 (efi)
- fortanix/rust-sgx#770 (sgx)
- hermit-os/hermit-rs#718 (hermit)
- bytecodealliance/wasi-rs#108 (wasi)
- gimli-rs/addr2line#345
- oyvindln/adler2#2
- BurntSushi/memchr#180
- Frommi/miniz_oxide#173
- gimli-rs/object#777

try-job: x86_64-gnu
try-job: test-various
…twco

retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features

`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.

It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.

Also this PR forbids to specify those target features manually (warning).

Issue: rust-lang#116852
add `extern "custom"` functions

tracking issue: rust-lang#140829
previous discussion: rust-lang#140566

In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.

The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.

At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.

r? `@traviscross`
cc `@tgross35`

try-job: x86_64-apple-2
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#128425 (Make `missing_fragment_specifier` an unconditional error)
 - rust-lang#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features)
 - rust-lang#140770 (add `extern "custom"` functions)
 - rust-lang#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches)
 - rust-lang#142248 (Add supported asm types for LoongArch32)
 - rust-lang#142267 (assert more in release in `rustc_ast_lowering`)
 - rust-lang#142274 (Update the stdarch submodule)
 - rust-lang#142276 (Update dependencies in `library/Cargo.lock`)
 - rust-lang#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library)

Failed merges:

 - rust-lang#140920 (Extract some shared code from codegen backend target feature handling)

r? `@ghost`
`@rustbot` modify labels: rollup

try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
Unimplement unsized_locals

Implements rust-lang/compiler-team#630

Tracking issue here: rust-lang#111942

Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.

There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas

cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``

``@rustbot`` label F-unsized_locals

Fixes rust-lang#79409
…ngjubilee

Simplify implementation of Rust intrinsics by using type parameters in the cache

The current implementation of intrinsics have a lot of duplication to handle different overloads of overloaded LLVM intrinsic. This PR uses the **base name and the type parameters** in the cache instead of the full, overloaded name. This has the benefit that `call_intrinsic` doesn't need to provide the full name, rather the type parameters (which is most of the time more available). This uses `LLVMIntrinsicCopyOverloadedName2` to get the overloaded name from the base name and the type parameters, and only uses it to declare the function.

(originally was part of rust-lang#140763, split off later)

`@rustbot` label A-codegen A-LLVM
r? codegen
…ork, r=workingjubilee,saethlin

Move metadata object generation for dylibs to the linker code

This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.

Prerequisite of rust-lang#96708.
As in many previous commits, adding the new traits to minicore, but this
time for cranelift and gcc.
Sized Hierarchy: Part I

This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.

There are no edition migrations implemented in this,  as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in rust-lang#137944 (comment)

Fixes rust-lang#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
@rustbot rustbot added 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 Jun 30, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jun 30, 2025

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Copy link
Contributor

@antoyo antoyo left a comment

Choose a reason for hiding this comment

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

Thanks a lot!

@GuillaumeGomez
Copy link
Member Author

@bors r+ p=1

@bors
Copy link
Collaborator

bors commented Jun 30, 2025

📌 Commit 666934a has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors 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-review Status: Awaiting review from the assignee but also interested parties. labels Jun 30, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 30, 2025
…cc_2025-06-30, r=GuillaumeGomez

GCC backend subtree update

cc `@antoyo`

r? ghost
bors added a commit that referenced this pull request Jun 30, 2025
Rollup of 5 pull requests

Successful merges:

 - #143156 (inherit `#[align]` from trait method prototypes)
 - #143223 (Improve macro stats printing)
 - #143229 ([COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary)
 - #143239 (GCC backend subtree update)
 - #143246 (Subtree update of `rust-analyzer`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Collaborator

bors commented Jun 30, 2025

⌛ Testing commit 666934a with merge f26e580...

@bors
Copy link
Collaborator

bors commented Jun 30, 2025

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing f26e580 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 30, 2025
@bors bors merged commit f26e580 into rust-lang:master Jun 30, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jun 30, 2025
@GuillaumeGomez GuillaumeGomez deleted the subtree-update_cg_gcc_2025-06-30 branch June 30, 2025 22:36
Copy link
Contributor

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 c65dcca (parent) -> f26e580 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard f26e58023071e71636a3c72ac3a2bf89b1f76706 --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. x86_64-apple-1: 11009.0s -> 5908.1s (-46.3%)
  2. dist-aarch64-linux: 5682.2s -> 7762.7s (36.6%)
  3. x86_64-apple-2: 5789.8s -> 3888.0s (-32.8%)
  4. dist-apple-various: 8764.3s -> 6602.2s (-24.7%)
  5. dist-x86_64-apple: 10365.0s -> 12877.4s (24.2%)
  6. x86_64-rust-for-linux: 3164.3s -> 2615.8s (-17.3%)
  7. x86_64-msvc-1: 10070.4s -> 8472.0s (-15.9%)
  8. i686-gnu-2: 6240.9s -> 5384.6s (-13.7%)
  9. mingw-check-1: 1802.2s -> 1558.2s (-13.5%)
  10. aarch64-gnu-debug: 3962.6s -> 3521.6s (-11.1%)
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
Copy link
Collaborator

Finished benchmarking commit (f26e580): 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.3%, secondary 2.0%)

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

mean range count
Regressions ❌
(primary)
2.3% [0.8%, 2.9%] 4
Regressions ❌
(secondary)
2.0% [0.4%, 3.2%] 36
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.3% [0.8%, 2.9%] 4

Cycles

Results (secondary -0.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)
0.6% [0.5%, 0.8%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.7% [-1.0%, -0.6%] 3
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 694.972s -> 696.724s (0.25%)
Artifact size: 372.21 MiB -> 372.22 MiB (0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.