Sync from rust 2026/09/04 - #972
Open
antoyo wants to merge 25 commits into
Open
Conversation
This will allow introducing a separate incr comp session dir for the post LTO artifacts in the future. In addition it statically encodes the lifetime of the incr comp session rather than requiring an enum behind a mutex stored in the Session.
Split IncrCompSession out of Session This will allow introducing a separate incr comp session dir for the post LTO artifacts in the future. In addition it statically encodes the lifetime of the incr comp session rather than requiring an enum behind a mutex stored in the Session. Based on rust-lang/rust#159000 Part of rust-lang/compiler-team#908
…rcote refactor handling of target features in Session `Session` currently contains two lists of target features: `target_features`, which is also exposed in `cfg`, and `unstable_target_features`, which is used internally to communicate between various parts of the compiler which target features are *actually* available, including some that we don't have plans to put in `cfg`, namely "forbidden" target features. The `unstable_target_features` list is *not* equivalent to what nightly code sees in `cfg(target_features)` as the latter excludes "forbidden" target features. Both lists are computed by `fn cfg_target_features` even though one of them is never used for `cfg`. It's all kind of messy. This PR refactors that: `fn cfg_target_features` is replaced by `fn internal_target_features` which computes all enabled Rust target features (including "forbidden" ones -- which are really more like "internal-only" ones so the 2nd commit renames them). We then compute `cfg(target_features)` from that. The session only stores one list, `internal_target_features`, which corresponds to the previous `unstable_target_features`. To simplify computing `internal_target_features` I also refactored `parse_rust_feature_list` to better distinguish actual Rust target features from unknown target features that we are just grandfathering in. I also made `implied_target_features` not rebuild the same hash map over and over again. And I got rid of a bunch of silly temporary vectors and iterations over all Rust target features.
- Upgrade from `getrandom v0.4.2` to `v0.4.3` to drop its `wasip2` and `wasip3` dependencies and many transitives. - Upgrade from `gimli v0.33` to `v0.34` as a direct dependency and through a `thorin-dwp` upgrade. - Upgrade from `object v0.37` and `v0.38` to `v0.39` as a direct dependency and via `ar_archive_writer` and `thorin-dwp` upgrades. - Upgrade `libloading` and `wasmparser` to match other dependencies. This also consolidates from `hashbrown v0.15`, `v0.16`, and `v0.17` to just `v0.17.1`, which is the same that `std` currently uses.
atomic volatile: add intrinsics Extend the atomic load/store intrinsics to also support volatile atomic load/store. Tracking issue: rust-lang/rust#158947. Library APIs that use these intrinsics will be added inn a future PR. The GCC and cranelift implementations ignore the volatile flag, not sure how that should be implemented for them.
so that we can specify more than one i32 of padding.
A naive `f32::mul_add(a as f32, b as f32, c as f32) as f16` has insufficient precision
Add floating point inline ASM support for SPARC This PR adds support for floating point registers to SPARC inline ASM. Ping target maintainers: @psumbera @kulikjak @jonathanpallant @mvolfik @he32 @0323pin @semarie Tracking issues: f16 inline ASM: rust-lang/rust#125398 (part of rust-lang/rust#116909) SPARC inline ASM: rust-lang/rust#93335
make `pad_i32` of `PassMode::cast` an integer
so that we can specify more than one i32 of padding. This PR only adds the functionality but does not yet use it: there should be no functional changes.
This is needed for the ABI of `Complex<{ float }>` on 32-bit powerpc. Other mechanisms, e.g. using `PassMode::prefixed` don't appear to work.
More discussion is in [#t-compiler/help > power complex abi](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/power.20complex.20abi/with/613294420).
…gross35 test `f16::mul_add` not double-rounding the result test the precision of `f16::mul_add`. The semantics of `mul_add` are that there should only be one rounding of the final result back into the storage type, i.e. the intermediate result of the multiplication should not be rounded. A naive implementation of `f16::mul_add` as `f32::mul_add(a as f32, b as f32, c as f32) as f16` has insufficient precision, see llvm/llvm-project#98389. Our `rustc_codegen_gcc` backend still used the `f32` approach, this PR changes it to instead (implicitly) use the fallback body from `core`, which uses `f64::mul_add` so that the result is correctly rounded.
Add MSA and `f16` inline ASM support for MIPS This PR adds vector register support for MIPS inline ASM when using the MSA extension ([MSA specification](https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00868-1D-MSA64-AFP-01.12.pdf)), as well as adding support for the `f16` type. Ping target maintainers of MIPS targets: @Itus-Shield @Gelbpunkt @ayrtonm @LukasWoodtli @wzssyqa @chenx97 @709924470 @Cyanoxygen @Fearyncess Tracking issues: `f16` inline ASM: rust-lang/rust#125398 (part of rust-lang/rust#116909) MIPS inline ASM: rust-lang/rust#93335 MIPS target features: rust-lang/rust#150253
…=Amanieu support `#[target_feature(enable = ...)]` on `#[naked]` functions fixes rust-lang/rust#136280 Instructions that are part of a target feature require a special directive on some targets. This PR adds those for the most common targets. This is very WIP, but I'm hoping to collect some feedback on what is (not) supported and how to report that to users. r? @ghost cc @taiki-e @Amanieu
…lkertdev Make sin, cos, exp, exp2, log, log2, log10 generic Rebased and smaller version of rust-lang/rust#153934 Following `fabs`, make the `sin`, `cos`, `exp`, `exp2`, `log`, `log2` and `log10` intrinsics generic over the float type, rather than having four variants per float type. The first two commits are purely stylistic: - reorganised Cranelift code to make following changes simpler - moved a misplaced comment in `compiler/rustc_codegen_llvm/src/intrinsic.rs` that caused `x fmt` to give up The last commit actually makes them generic! Most code is a bit simpler, ~~and this will also hopefully simplify adding support for these intrinsics for the future [`bf16` type](rust-lang/rust#160859 :) Unfortunately both GCC and Cranelift backend changes are a bit churny. Their code is a bit, opaque, to put it kindly, and I didn't want to refactor those here. r? @folkertdev cc @RalfJung
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.