-
Notifications
You must be signed in to change notification settings - Fork 13.5k
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
GCC backend subtree update #143239
Conversation
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
…o enable retpoline-related target features
…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
…lexcrichton Remove wasm legacy abi Closes rust-lang#122532 Closes rust-lang#138762 Fixes rust-lang#71871 rust-lang#88152 Fixes rust-lang#115666 Fixes rust-lang#129486
…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)
…6_28 Sync from rust 2025/06/28
Fix const_undef
…update_cg_gcc_2025-06-30
Some changes occurred in compiler/rustc_codegen_gcc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot!
@bors r+ p=1 |
…cc_2025-06-30, r=GuillaumeGomez GCC backend subtree update cc `@antoyo` r? ghost
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
☀️ Test successful - checks-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 c65dcca (parent) -> f26e580 (this PR) Test differencesNo test diffs found Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard f26e58023071e71636a3c72ac3a2bf89b1f76706 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (f26e580): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis 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.
CyclesResults (secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 694.972s -> 696.724s (0.25%) |
cc @antoyo
r? ghost