Rollup of 6 pull requests#159573
Closed
JonathanBrouwer wants to merge 15 commits into
Closed
Conversation
- Boolean target modifiers are now mentioned without a trailing `=` in the messages. - Wording improved for unset target modifiers.
…and NVPTX For AVR, AMDGCN, and NVPTX, crates built with different target CPU values are not generally link-compatible. Add a `requires_consistent_cpu` flag to the target spec and enable it for these targets. When the flag is set, treat `-Ctarget-cpu` as a target modifier and require all linked crates to agree on its value. Reject `-Ctarget-cpu=native` before codegen for targets that set `requires_consistent_cpu` to true. Also do not include `native` in the printed `target-cpus` list for such targets. Add tests covering: - which built-in targets set `requires-consistent-cpu` - cross-crate behavior with and without `requires-consistent-cpu` - that an omitted `-Ctarget-cpu` compares equal to an explicitly specified default CPU - rejection and printing behavior for `native` - precedence of repeated `-Ctarget-cpu` flags in metadata comparison and LLVM IR
…k-Simulacrum
Always generate private and hidden items in JSON docs of the stdlib
This data is needed for downstream tools, e.g. cargo-semver-checks, to analyse the whole stdlib.
For the HTML output it is configurable using `build.library-docs-private-items`, but to avoid adding a separate config for just the JSON format, I think that we can just enable it unconditionally.
An alternative would be to change the flag from a bool to something like
```rust
enum StdDocsPrivateItems {
No,
Yes,
Html,
Json
}
```
…am_epoch, r=Mark-Simulacrum Update rustc crate crossbeam-epoch to 0.9.20 See https://rustsec.org/advisories/RUSTSEC-2026-0204.html and crossbeam-rs/crossbeam#1276
…orn3 Convert `-Ctarget-cpu` into a target-modifier for AVR, AMDGCN and NVPTX Crates built for AVR, AMDGCN and NVPTX that specify different values for `-Ctarget-cpu` cannot be soundly linked together. This PR attempts to make `rustc` ensure that no crates with disagreeing values for `-Ctarget-cpu` are linked together. This is achieved by converting `-Ctarget-cpu` into a target-modifier depending on `--target`. To do this, the consistency check for `-Ctarget-cpu` considers mismatching values as inconsistent only for targets for which the new flag `requires_consistent_cpu` is set in their target spec. **Why should `-Ctarget-cpu` be a target-modifier for `nvptx`?** <details><summary>PTX is a single-module contract</summary> <p> PTX requires a binary to start with .version (`ptx$$`) then .target (`sm_$$`). If the ptx contains instructions that are not supported by either .version or .target, the binary is ill-formed and will be rejected by ptxas. The concept of features that can be mixed and matched in a binary does not exist for nvptx and is therefore not supported by LLVM. </p> </details> <details><summary>It prevents the production of bitcode that cannot be codegen'd after linking</summary> <p> A target modifier should prevent configurations that are not composable across crates when those crates are linked together. The most prominent example is when enabling a target feature changes the ABI, making cross-crate calls inherently unsound. In the case of nvptx, ABI mismatch is (at least for now) not the core problem motivating target modifiers. NVIDIA’s documented PTX calling convention has [remained stable since ptx20](https://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/index.html#function-calling-sequence). However, in the current state it is possible to produce bitcode that cannot be codegen'd after linking, because some operations are only lowerable for sufficiently new SM/PTX levels. In the best case this results in an LLVM error during the final llc step, but this is not something we should rely on for correctness. nvptx has a special compilation pipeline where instead of linking the final PTX object, instead LLVM bitcode is linked. The resulting artifact is then compiled in one invocation. Now consider crate A which is independently compiled into bitcode with the following rustc arguments: ```Rust //@ compile-flags: --target nvptx64-nvidia-cuda -C target-cpu=sm_70 --crate-type=rlib #[cfg(target_feature = "sm_70")] fn foo() { // cannot be lowered to ptx before "sm_70: so currently produces an LLVM error } #[cfg(not(target_feature = "sm_70"))] fn foo() { // can be lowered to ptx before "sm_70" } pub fn bar() { foo() } ``` Crate A is a dependency of crate B. In the *rustc* invocation of crate B 1. crate B is compiled into bitcode, too 2. both bitcode artifacts are bitcode-linked by *llvm-link* 3. the resulting bitcode artifact is compiled by *llc -mcpu=sm_60* This should now ideally create an LLVM error, because the linked bitcode contains code paths that were selected under `sm_70` assumptions but the final NVPTX codegen is targeting `sm_60`, where those operations are not lowerable. An LLVM error here is better than silent miscompilation, but it’s not a promise we should rely on. A real example where this could happen is the lowering of atomic loads and stores with non-relaxed orderings, which is known to depend on the selected SM level. </p> </details> **Why should `-Ctarget-cpu` be a target-modifier for `amdgcn` and `avr`?** - In case of AVR the target-cpu defines the ISA, which is encoded in the ELF header flags, amdgcn also encodes the cpu directly into those flags - To not rely on *lld* which currently prevents it for both by looking at those flags [AVR](https://github.com/llvm/llvm-project/blob/597ffbe09d5f774f861ee55e50022bf84d7f98e2/lld/test/ELF/avr-flags.s) and [amdgcn](https://github.com/llvm/llvm-project/blob/597ffbe09d5f774f861ee55e50022bf84d7f98e2/lld/test/ELF/amdgpu-elf-flags-err.s) Previous discussions about the topic can be found [here](rust-lang#131799 (comment)) and [here](rust-lang#141468). I also created a [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Making.20-Ctarget-cpu.20a.20target-modifier.20on.20NVPTX/with/566622679). I am unsure if a MCP is needed before proceeding. If you think so please let me know. Creating *target-modifiers* for NVPTX *target-features* is to be done in a follow-up. cc @kjetilkjeka as target maintainer for NVPTX cc @Flakebi as target maintainer for amdgcn cc @Patryk27 as target maintainer for AVR cc @RalfJung you were very involved in the discussions so far Target modifier tracking issue: rust-lang#136966
…rust-lang#151770, r=Mark-Simulacrum Add mul_add_relaxed methods for floating-point types Implements mul_add_relaxed for f16, f32, f64, and f128, which computes (self * a) + b with relaxed precision semantics. Unlike mul_add which guarantees a fused operation, this variant allows the compiler to choose between fused or separate operations based on target performance. This fills the gap between the precision-guaranteed mul_add and the fully-optimizable algebraic operators, providing target-specific optimization while maintaining reasonable floating-point semantics. Tracking issue: rust-lang#151770
…ark-Simulacrum restrict const-eval-related 'content' triggers to library/ folder Cc @rust-lang/wg-const-eval The 2nd commit is a drive-by fix.
fix ICE in opsem inhabitedness check I feel like maybe rust-lang#159560 should be avoided by not even trying to evaluate this constant... but anyway it makes sense to make this query tolerant to `ty::Error` IMO. The error message we emit still makes no sense, but that's a separate issue and better than ICEing. Fixes rust-lang#159560 r? @oli-obk
rustbot
added
A-LLVM
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 19, 2026
Rollup of 6 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-*
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 19, 2026
…uwer Rollup of 6 pull requests Successful merges: - #159188 (Always generate private and hidden items in JSON docs of the stdlib) - #159567 (Update rustc crate crossbeam-epoch to 0.9.20) - #150732 (Convert `-Ctarget-cpu` into a target-modifier for AVR, AMDGCN and NVPTX ) - #151793 (Add mul_add_relaxed methods for floating-point types) - #159549 (restrict const-eval-related 'content' triggers to library/ folder) - #159570 (fix ICE in opsem inhabitedness check)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for 8f3c877 failed: CI. Failed job:
|
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
PR #151793, which is a member of this rollup, was unapproved. |
rust-bors
Bot
removed
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-author
Contributor
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
8 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.
Successful merges:
-Ctarget-cpuinto a target-modifier for AVR, AMDGCN and NVPTX #150732 (Convert-Ctarget-cpuinto a target-modifier for AVR, AMDGCN and NVPTX )r? @ghost
Create a similar rollup