rust/compiler/rustc_codegen_ssa/src, branch try

Rollup merge of #142097 - ZuseZ4:offload-host1, r=oli-obk

2025-07-21T16:54:24+00:00

gpu offload host code generation r? ghost This will generate most of the host side code to use llvm's offload feature. The first PR will only handle automatic mem-transfers to and from the device. So if a user calls a kernel, we will copy inputs back and forth, but we won't do the actual kernel launch. Before merging, we will use LLVM's Info infrastructure to verify that the memcopies match what openmp offloa generates in C++. `LIBOMPTARGET_INFO=-1 ./my_rust_binary` should print that a memcpy to and later from the device is happening. A follow-up PR will generate the actual device-side kernel which will then do computations on the GPU. A third PR will implement manual host2device and device2host functionality, but the goal is to minimize cases where a user has to overwrite our default handling due to performance issues. I'm trying to get a full MVP out first, so this just recognizes GPU functions based on magic names. The final frontend will obviously move this over to use proper macros, like I'm already doing it for the autodiff work. This work will also be compatible with std::autodiff, so one can differentiate GPU kernels. Tracking: - https://github.com/rust-lang/rust/issues/131513

Ban projecting into SIMD types [MCP838]

2025-07-20T17:22:09+00:00

Rollup merge of #144143 - Gelbpunkt:target-features-crt-static, r=RalfJung

2025-07-20T13:34:07+00:00

Fix `-Ctarget-feature`s getting ignored after `crt-static` The current behaviour introduced by commit a50a3b8e318594c41783294e440d864763e412ef would discard any target features specified after `crt-static` (the only member of `RUSTC_SPECIFIC_FEATURES`). This is because it returned instead of continuing processing the next feature. I wasn't entirely sure how the regression test should look like, but this one should do. If anyone has some suggestions, I'm happy to learn, it's my first test :) I've confirmed that the test fails without the fix on `powerpc64le-unknown-linux-musl` and `x86_64-unknown-linux-gnu`. cc ``@RalfJung``

Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too

2025-07-20T03:50:02+00:00

The conversation in 143502 made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all. This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true. I'll try out such a world next :)

Auto merge of #143784 - scottmcm:enums-again-new-ex2, r=dianqk

2025-07-19T08:03:40+00:00

Simplify discriminant codegen for niche-encoded variants which don't wrap across an integer boundary Inspired by rust-lang/rust#139729, this attempts to be a much-simpler and more-localized change while still making a difference. (Specifically, this does not try to solve the problem with select-sinking, leaving that to be fixed by https://github.com/llvm/llvm-project/issues/134024 -- once it gets released -- instead of in rustc's codegen.) What this *does* improve is checking for the variant in a 3+ variant enum when that variant is the type providing the niche. Something like `if let Foo::WithBool(_) = ...` previously compiled to `ugt(add(x, -2), 2)`, which is non-trivial to think about because it's depending on the unsigned wrapping to shift the 0/1 up above 2. With this PR it compiles to just `ult(x, 2)`, which is probably what you'd have written yourself if you were doing it by hand to look for "is this byte a bool?". That's done by leaving most of the codegen alone, but adding a couple new special cases to the `is_niche` check. The default looks at the relative discriminant, but in the common cases where there's no wraparound involved, we can just check the original value, rather than the offsetted one. The first commit just adds some tests, so the best way to see the effect of this change is to look at the second commit and how it updates the test expectations.

add -Zoffload=Enable flag behind -Zunstable-options, to enable gpu (host) code generation

2025-07-18T23:24:00+00:00

rustc_codegen_ssa: Don't skip target-features after crt-static

2025-07-18T16:59:13+00:00

The current behaviour introduced by commit a50a3b8e318594c41783294e440d864763e412ef would discard any target features specified after crt-static (the only member of RUSTC_SPECIFIC_FEATURES). This is because it returned instead of continuing processing the next flag. Signed-off-by: Jens Reidel

Rollup merge of #143846 - usamoi:gc, r=bjorn3

2025-07-18T02:27:52+00:00

pass --gc-sections if -Zexport-executable-symbols is enabled and improve tests Exported symbols are added as GC roots in linking, so `--gc-sections` won't hurt `-Zexport-executable-symbols`. Fixes the run-make test to work on Linux. Enable the ui test on more targets. cc rust-lang/rust#84161

Rollup merge of #143293 - folkertdev:naked-function-kcfi, r=compiler-errors

2025-07-18T02:27:51+00:00

fix `-Zsanitizer=kcfi` on `#[naked]` functions fixes https://github.com/rust-lang/rust/issues/143266 With `-Zsanitizer=kcfi`, indirect calls happen via generated intermediate shim that forwards the call. The generated shim preserves the attributes of the original, including `#[unsafe(naked)]`. The shim is not a naked function though, and violates its invariants (like having a body that consists of a single `naked_asm!` call). My fix here is to match on the `InstanceKind`, and only use `codegen_naked_asm` when the instance is not a `ReifyShim`. That does beg the question whether there are other `InstanceKind`s that could come up. As far as I can tell the answer is no: calling via `dyn` seems to work find, and `#[track_caller]` is disallowed in combination with `#[naked]`. r? codegen ````@rustbot```` label +A-naked cc ````@maurer```` ````@rcvalle````

remove no_gc_sections

2025-07-17T06:54:52+00:00