Rollup of 7 pull requests#154514
Closed
JonathanBrouwer wants to merge 17 commits intorust-lang:mainfrom
Closed
Conversation
For `gnu` function_sections is off by default.
Add `bounds::FloatPrimitive` Exhaustive float pattern match Fix GCC use span bugs
…, r=Amanieu naked functions: respect `function-sections` fixes rust-lang#147789 r? @Amanieu
…tgross35,RalfJung Merge `fabsf16/32/64/128` into `fabs::<F>` Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :) This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target. Notes: - I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs. - Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs - `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`. - I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!
…alebzulawski,antoyo simd_fmin/fmax: make semantics and name consistent with scalar intrinsics This is the SIMD version of rust-lang#153343: change the documented semantics of the SIMD float min/max intrinsics to that of the scalar intrinsics, and also make the name consistent. The overall semantic change this amounts to is that we restrict the non-determinism: the old semantics effectively mean "when one input is an SNaN, the result non-deterministically is a NaN or the other input"; the new semantics say that in this case the other input must be returned. For all other cases, old and new semantics are equivalent. This means all users of these intrinsics that were correct with the old semantics are still correct: the overall set of possible behaviors has become smaller, no new possible behaviors are being added. In terms of providers of this API: - Miri, GCC, and cranelift already implement the new semantics, so no changes are needed. - LLVM is adjusted to use `minimumnum nsz` instead of `minnum`, thus giving us the new semantics. In terms of consumers of this API: - Portable SIMD almost certainly wants to match the scalar behavior, so this is strictly a bugfix here. - Stdarch mostly stopped using the intrinsic, except on nvptx, where arguably the new semantics are closer to what we actually want than the old semantics (rust-lang/stdarch#2056). Q: Should there be an `f` in the intrinsic name to indicate that it is for floats? E.g., `simd_fminimum_number_nsz`? Also see rust-lang#153395.
…ark-Simulacrum triagebot: add reminder for bumping CI LLVM stamp I'm not sure what else can be done automatically to help us not forget this, but at least this gives a chance for the PR author/reviewer to be reminded (e.g. myself).
…alueFormat-dist-x86_64, r=marcoieni Fix LegacyKeyValueFormat report from docker build: dist-x86_64 Part of rust-lang#152305 r? @marcoieni
…s, r=Mark-Simulacrum `trim_prefix` for paths under rust-lang#142312? its a useful method.
…triddle Fix ice in rustdoc of private reexport Fixes rust-lang#154383 The root cause is rustdoc could still try to resolve links for source docs that resolver did not cache in `ResolveDocLinks::Exported` mode. The test case will not crash with `--document-private-items` option, which will use `ResolveDocLinks::All`. The fix makes rustdoc skip link resolution based on the source `DefId` of each doc fragment, so its behavior stays aligned with resolver's logic here: https://github.com/chenyukang/rust/blob/dc5cb1719eed6ac9275fe93d914d32141606b2ac/compiler/rustc_resolve/src/late.rs#L685
rustbot
added
A-CI
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
the
S-waiting-on-bors
Contributor
Author
|
Trying commonly failed jobs |
rust-bors
bot
removed
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 28, 2026
Rollup of 7 pull requests 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
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 28, 2026
…uwer Rollup of 7 pull requests Successful merges: - #147811 (naked functions: respect `function-sections`) - #153834 (Merge `fabsf16/32/64/128` into `fabs::<F>`) - #154043 (simd_fmin/fmax: make semantics and name consistent with scalar intrinsics) - #154494 (triagebot: add reminder for bumping CI LLVM stamp) - #153374 (Fix LegacyKeyValueFormat report from docker build: dist-x86_64) - #154320 (`trim_prefix` for paths) - #154453 (Fix ice in rustdoc of private reexport)
rust-bors
bot
added
S-waiting-on-review
Contributor
|
💔 Test for e8e59d1 failed: CI. Failed job:
|
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
bot
added
S-waiting-on-author
Contributor
|
PR #147811, which is a member of this rollup, was unapproved. |
Contributor
|
💔 Test for 20f2e9f failed: CI. Failed jobs:
|
rustbot
removed
the
S-waiting-on-author
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
10 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:
function-sections#147811 (naked functions: respectfunction-sections)fabsf16/32/64/128intofabs::<F>#153834 (Mergefabsf16/32/64/128intofabs::<F>)trim_prefixfor paths #154320 (trim_prefixfor paths)r? @ghost
Create a similar rollup