about summary refs log tree commit diff
path: root/compiler/rustc_codegen_gcc/src
AgeCommit message (Collapse)AuthorLines
2025-07-05Make tempfile a normal dependencyDiggory Blake-4/+2
2025-07-05Use `object` crate from crates.io to fix windows build errorDiggory Blake-1/+0
2025-07-03Make __rust_alloc_error_handler_should_panic a functionDaniel Paoliello-11/+33
2025-07-03Merge run_fat_lto, optimize_fat and autodiff into run_and_optimize_fat_ltobjorn3-17/+6
2025-07-03Remove unused config param from WriteBackendMethods::autodiffbjorn3-1/+0
2025-07-03Move dcx creation into WriteBackendMethods::codegenbjorn3-3/+4
2025-07-03Remove LtoModuleCodegenbjorn3-11/+10
Most uses of it either contain a fat or thin lto module. Only WorkItem::LTO could contain both, but splitting that enum variant doesn't complicate things much.
2025-06-30Auto merge of #143254 - matthiaskrgr:rollup-7x8bxek, r=matthiaskrgrbors-1/+1
Rollup of 9 pull requests Successful merges: - rust-lang/rust#143019 (Ensure -V --verbose processes both codegen_backend and codegen-backend) - rust-lang/rust#143140 (give Pointer::into_parts a more scary name and offer a safer alternative) - rust-lang/rust#143175 (Make combining LLD with external LLVM config a hard error) - rust-lang/rust#143180 (Use `tracing-forest` instead of `tracing-tree` for bootstrap tracing) - rust-lang/rust#143223 (Improve macro stats printing) - rust-lang/rust#143228 (Handle build scripts better in `-Zmacro-stats` output.) - rust-lang/rust#143229 ([COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary) - rust-lang/rust#143246 (Subtree update of `rust-analyzer`) - rust-lang/rust#143248 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
2025-06-30Rollup merge of #143140 - RalfJung:ptr-into-parts, r=oli-obkMatthias Krüger-1/+1
give Pointer::into_parts a more scary name and offer a safer alternative `into_parts` is a bit too innocent of a name for a somewhat subtle operation. r? `@oli-obk`
2025-06-30Merge commit '4b5c44b14166083eef8d71f15f5ea1f53fc976a0' into ↵Guillaume Gomez-113/+121
subtree-update_cg_gcc_2025-06-30
2025-06-29Rollup merge of #142078 - sayantn:more-intrinsics, r=workingjubileeGuillaume Gomez-0/+2
Add SIMD funnel shift and round-to-even intrinsics This PR adds 3 new SIMD intrinsics - `simd_funnel_shl` - funnel shift left - `simd_funnel_shr` - funnel shift right - `simd_round_ties_even` (vector version of `round_ties_even_fN`) TODO (future PR): implement `simd_fsh{l,r}` in miri, cg_gcc and cg_clif (it is surprisingly hard to implement without branches, the common tricks that rotate uses doesn't work because we have 2 elements now. e.g, the `-n&31` trick used by cg_gcc to implement rotate doesn't work with this because then `fshl(a, b, 0)` will be `a | b`) [#t-compiler > More SIMD intrinsics](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/More.20SIMD.20intrinsics/with/522130286) `@rustbot` label T-compiler T-libs A-intrinsics F-core_intrinsics r? `@workingjubilee`
2025-06-29Remove `()` returned valueGuillaume Gomez-1/+1
2025-06-29give Pointer::into_parts a more scary name and offer a safer alternativeRalf Jung-1/+1
2025-06-29Fix signature of `filter_landing_pad`Guillaume Gomez-2/+2
2025-06-28Remove unwanted semi-colon in `rustc_codegen_gcc`Guillaume Gomez-1/+1
2025-06-28Merge commit 'b7091eca6d8eb0fe88b58cc9a7aec405d8de5b85' into ↵Guillaume Gomez-67/+76
subtree-update_cg_gcc_2025-06-28
2025-06-27rustc_codegen_gcc: Fix clippy::manual_is_multiple_ofPhilipp Krones-2/+3
2025-06-22Remove dead instructions in terminate blocksMark Rousskov-2/+2
2025-06-19various minor target feature cleanupsRalf Jung-2/+1
2025-06-19cg_gcc: properly populate cfg(target_features) with -Ctarget-featuresRalf Jung-22/+17
2025-06-19move -Ctarget-feature handling into shared codeRalf Jung-125/+25
2025-06-19move cfg(target_feature) computation into shared placeRalf Jung-37/+22
2025-06-18GCC backend: Remove `add_eval` if no function is createdGuillaume Gomez-1/+0
2025-06-18Merge commit 'fda0bb9588912a3e0606e880ca9f6e913cf8a5a4' into ↵Guillaume Gomez-10055/+10525
subtree-update_cg_gcc_2025-06-18
2025-06-18Auto merge of #141061 - dpaoliello:shimasfn, r=bjorn3bors-36/+42
Change __rust_no_alloc_shim_is_unstable to be a function This fixes a long sequence of issues: 1. A customer reported that building for Arm64EC was broken: #138541 2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well. 3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data. 4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not). 5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning. 6. A customer then reported a similar warning when using `lld-link` (<https://github.com/rust-lang/rust/pull/140176#issuecomment-2872448443>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: #140954. 7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <https://github.com/rust-lang/rust/pull/140176#issuecomment-2881867433>. At that point, my original change was reverted (#141024) leaving Arm64EC broken yet again. Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported. Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not. There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above. There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics). Build with this change applied BEFORE #140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205> Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for #128602) r? `@bjorn3` cc `@jieyouxu`
2025-06-16Change __rust_no_alloc_shim_is_unstable to be a functionDaniel Paoliello-36/+42
2025-06-16Fix RISC-V C function ABI when passing/returning structs containing floatsbeetrees-1/+1
2025-06-15Rollup merge of #141769 - bjorn3:codegen_metadata_module_rework, ↵León Orell Valerian Liehr-15/+2
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 https://github.com/rust-lang/rust/issues/96708.
2025-06-15Rollup merge of #133952 - bjorn3:remove_wasm_legacy_abi, r=alexcrichtonLeón Orell Valerian Liehr-16/+2
Remove wasm legacy abi Closes https://github.com/rust-lang/rust/issues/122532 Closes https://github.com/rust-lang/rust/issues/138762 Fixes https://github.com/rust-lang/rust/issues/71871 https://github.com/rust-lang/rust/issues/88152 Fixes https://github.com/rust-lang/rust/issues/115666 Fixes https://github.com/rust-lang/rust/issues/129486
2025-06-15Implement `simd_round_ties_even` for miri, cg_clif and cg_gccsayantn-0/+2
2025-06-14Auto merge of #142259 - sayantn:simplify-intrinsics, r=workingjubileebors-1/+1
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/rust#140763, split off later) `@rustbot` label A-codegen A-LLVM r? codegen
2025-06-14Remove all support for wasm's legacy ABIbjorn3-16/+2
2025-06-13Rollup merge of #140770 - folkertdev:custom-abi, r=tgross35Matthias Krüger-1/+5
add `extern "custom"` functions tracking issue: rust-lang/rust#140829 previous discussion: https://github.com/rust-lang/rust/issues/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
2025-06-12add `extern "custom"` functionsFolkert de Vries-1/+5
2025-06-12Simplify implementation of Rust intrinsics by using type parameters in the cachesayantn-1/+1
2025-06-09-Zretpoline and -Zretpoline-external-thunk flags (target modifiers) to ↵Andrew Zhogin-32/+10
enable retpoline-related target features
2025-06-08Rollup merge of #142194 - bjorn3:less_unstable_features, r=jieyouxuJubilee-1/+1
Remove all unused feature gates from the compiler
2025-06-08Remove all unused feature gates from the compilerbjorn3-1/+1
2025-06-07store `target.min_global_align` as an `Align`Folkert de Vries-14/+2
2025-06-03Rollup merge of #141569 - workingjubilee:canonicalize-abi, r=bjorn3Matthias Krüger-48/+31
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", ```
2025-06-03cg_gcc: convert to CanonAbiJubilee Young-48/+31
2025-06-03Move metadata object generation for dylibs to the linker codebjorn3-4/+2
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
2025-06-03Only borrow EncodedMetadata in codegen_cratebjorn3-13/+2
And move passing it to the linker to the driver code.
2025-06-03Remove type_test from IntrinsicCallBuilderMethodsbjorn3-5/+0
It is only used within cg_llvm.
2025-06-03Remove get_dbg_loc from DebugInfoBuilderMethodsbjorn3-4/+0
It is only used within cg_llvm.
2025-05-30Directly use from_immediate for handling boolbjorn3-6/+3
2025-05-30Avoid computing function type for intrinsic instancesbjorn3-8/+3
2025-05-30Use layout field of OperandRef in generic_simd_intrinsicbjorn3-47/+41
2025-05-30Use layout field of OperandRef and PlaceRef in codegen_intrinsic_callbjorn3-10/+11
This avoids having to get the function signature.
2025-05-30Rollup merge of #141507 - RalfJung:atomic-intrinsics, r=bjorn3Matthias Krüger-5/+5
atomic_load intrinsic: use const generic parameter for ordering We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that! This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics. The first two commits are preparation and could be a separate PR if you prefer. `@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer... `@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-13 15:29:20 +0000