Rollup of 12 pull requests #137346
Merged
Rollup of 12 pull requests #137346
Conversation
This file contains 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
Bitcode linkers like llvm-bitcode-linker or bpf linker hand over the target features to llvm during link stage. During link stage the `TyCtxt` is already gone so it is not possible to create a query for the global backend features any longer. The features preserved in `Session.target_features` only incorporate target features known to rustc. This would contradict with the behaviour during codegen stage which also passes target features to llvm which are unknown to rustc. This commit adds target features as a field to the `CrateInfo` struct and queries the target features in its new function. This way the target features are preserved beyond tcx and available at link stage. To make sure the `global_backend_features` query is always registered even if the CodegenBackend does not register it, this registration is added to the `provide`function of the `rustc_codegen_ssa` crate.
The .ptx version produced by llc can be specified by passing it with --mattr. Currently it is not possible to specify the .ptx version with -Ctarget-feature because these are not passed through to llvm-bitcode-linker and handled by it. This commit adds both. --target-feature and -mattr are passed with equals to mitigate issues when the value starts with a - (minus).
This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-none` variant that must be specialized with the `-C target-cpu` flag (e.g. `-C target-cpu=atmega328p`).
The locations of these files have since been changed. This is a simple change to update the references to these files.
… 128bit While it would technically be possible to workaround this in cg_clif, it quickly becomes very messy and would likely cause correctness issues. Working around it in rustc instead is much simper and won't have any negative impact for code running on stable as vectors smaller than 128bit can only be made on nightly using core::simd or #[repr(simd)].
LLVM 20 enabled the `nontrapping-fptoint` and `bulk-memory` features by default, so this updates the corresponding documentation for the `wasm32-*` targets (which all point to `wasm32-unknown-unknown`). cc rust-lang#137315
…l` field in `LayoutData`. Also update comments that refered to BackendRepr::Uninhabited.
…PassMode::Ignore.
…turn ABI as wrapped type. Fix codegen of uninhabited PassMode::Indirect return types. Add codegen test for uninhabited PassMode::Indirect return types. Enable optimizations for uninhabited return type codegen test
Co-authored-by: Jubilee <workingjubilee@gmail.com>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
…ross35 Create a generic AVR target: avr-none This commit removes the `avr-unknown-gnu-atmega328` target and replaces it with a more generic `avr-none` variant that must be specialized using `-C target-cpu` (e.g. `-C target-cpu=atmega328p`). Seizing the day, I'm adding myself as the maintainer of this target - I've been already fixing the bugs anyway, might as well make it official 🙂 Related discussions: - rust-lang#131171 - rust-lang/compiler-team#800 try-job: x86_64-gnu-debug
…d, r=scottmcm Stabilize `num_midpoint_signed` feature This PR proposes that we stabilize the signed variants of [`iN::midpoint`](rust-lang#110840 (comment)), the operation is equivalent to doing `(a + b) / 2` in a sufficiently large number. The stabilized API surface would be: ```rust /// Calculates the middle point of `self` and `rhs`. /// /// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a /// sufficiently-large signed integer type. This implies that the result is /// always rounded towards zero and that no overflow will ever occur. impl i{8,16,32,64,128,size} { pub const fn midpoint(self, rhs: Self) -> Self; } ``` T-libs-api previously stabilized the unsigned (and float) variants in rust-lang#131784, the signed variants were left out because of the rounding that should be used in case of negative midpoint. This stabilization proposal proposes that we round towards zero because: - it makes the obvious `(a + b) / 2` in a sufficiently-large number always true - using another rounding for the positive result would be inconsistent with the unsigned variants - it makes `midpoint(-a, -b)` == `-midpoint(a, b)` always true - it is consistent with `midpoint(a as f64, b as f64) as i64` - it makes it possible to always suggest `midpoint` as a replacement for `(a + b) / 2` expressions *(which we may want to do as a future work given the 21.2k hits on [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%5C%28%5Ba-zA-Z_%5D*+%5C%2B+%5Ba-zA-Z_%5D*%5C%29+%5C%2F+2%2F&type=code&p=1))* `@scottmcm` mentioned a drawback in rust-lang#132191 (comment): > I'm torn, because rounding towards zero makes it "wider" than other values, which `>> 1` avoids -- `(a + b) >> 1` has the nice behaviour that `midpoint(a, b) + 2 == midpoint(a + 2, b + 2)`. > > But I guess overall sticking with `(a + b) / 2` makes sense as well, and I do like the negation property 🤷 Which I think is outweigh by the advantages cited above. Closes rust-lang#110840 cc `@rust-lang/libs-api` cc `@scottmcm` r? `@dtolnay`
…chenkov infer linker flavor by linker name if it's sufficiently specific Fix: `rustc` does not infer `llvm-bitcode-linker` uses `llbc` linker flavor if targeting `nvptx64-nvidia-cuda`.
Pass through of target features to llvm-bitcode-linker and handling them When using the llvm-bitcode-linker (`linker-flavor=llbc`) target-features are not passed through and are not handled by it. The llvm-bitcode-linker is mainly used as a self contained linker to link llvm bitcode for the nvptx64 target. It uses `llvm-link`, `opt` and `llc` internally. To produce a `.ptx` file of a specific ptx-version it is necessary to pass the version to llc with the `--mattr` option. Without explicitly setting it, the emitted `.ptx`-version is the minimum supported version of the `--target-cpu`. I would like to be able to explicitly set the ptx version as [some llvm problems only occur in earlier `.ptx`-versions](llvm/llvm-project#112998). Therefore this pull request adds support for passing target features to llvm-bitcode-linker and handling them. I was not quite sure if adding these features to `rustc_target/src/target_features.rs` is necessary or not. If so I will gladly add these. r? ``@kjetilkjeka``
…bited, r=workingjubilee Do not ignore uninhabited types for function-call ABI purposes. (Remove BackendRepr::Uninhabited) Accepted MCP: rust-lang/compiler-team#832 Fixes rust-lang#135802 Do not consider the inhabitedness of a type for function call ABI purposes. * Remove the [`rustc_abi::BackendRepr::Uninhabited`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html) variant * Instead calculate the `BackendRepr` of uninhabited types "normally" (as though they were not uninhabited "at the top level", but still considering inhabitedness of variants to determine enum layout, etc) * Add an `uninhabited: bool` field to [`rustc_abi::LayoutData`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/struct.LayoutData.html) so inhabitedness of a `LayoutData` can still be queried when necessary (e.g. when determining if an enum variant needs a tag value allocated to it). This should not affect type layouts (size/align/field offset); this should only affect function call ABI, and only of uninhabited types. cc ``@RalfJung``
Fix `*-win7-windows-msvc` target since 26eeac1 That commit make it failed to build `std` with `*-win7-windows-msvc` so fix it.
Update references to cc_detect.rs The locations of these file references have since been changed. This is a simple change to update the references to this `cc_detect.rs` file.
…orkingjubilee Workaround Cranelift not yet properly supporting vectors smaller than 128bit While it would technically be possible to workaround this in cg_clif, it quickly becomes very messy and would likely cause correctness issues. Working around it in rustc instead is much simper and won't have any negative impact for code running on stable as vectors smaller than 128bit can only be made on nightly using core::simd or #[repr(simd)].
…ieyouxu Update docs for default features of wasm targets LLVM 20 enabled the `nontrapping-fptoint` and `bulk-memory` features by default, so this updates the corresponding documentation for the `wasm32-*` targets (which all point to `wasm32-unknown-unknown`). Closes rust-lang#137315 with a doc update for the doc part.
…6, r=workingjubilee Make x86 QNX target name consistent with other Rust targets Rename target to be consistent with other Rust targets: Use `i686` instead of `i586` See also - rust-lang#136495 - rust-lang#109173 CC: `@jonathanpallant` `@japaric` `@gh-tr` `@samkearney`
skip submodule updating logics on tarballs Running submodule logic on tarballs isn't necessary since git isn't available there. Fixes rust-lang#137332
…-ozkan Add a notice about missing GCC sources into source tarballs I didn't use `.gitkeep`, because that would be a hidden file that might not be noticed, whereas we want to let people inspecting the archive know why the sources are missing. Inspired by rust-lang#137332. r? `@onur-ozkan`
rustbot
added
A-compiletest
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: f04bbc60f8 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Feb 21, 2025
|
Finished benchmarking commit (a18bd8a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 1.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary 2.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 774.477s -> 773.525s (-0.12%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
num_midpoint_signedfeature #134340 (Stabilizenum_midpoint_signedfeature)*-win7-windows-msvctarget since 26eeac1a1e9fe46ffd80dd0d3dafdd2c2a644306 #137270 (Fix*-win7-windows-msvctarget since 26eeac1)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup