tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size#153290
Merged
rust-bors[bot] merged 1 commit intorust-lang:mainfrom Mar 9, 2026
Conversation
… bound to __rust_alloc size LLVM emits a lower bound of 8 for the size parameter to __rust_alloc when targeting x86_64-unknown-hermit. Since that is also completely valid, relax the lower bound check.
rustbot
added
S-waiting-on-review
Collaborator
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Member
|
@bors r+ Not sure why this is specific to hermit. It seems like the range attribute is a bit useless regardless, since the exact constant is known at the call site in this case... Seems like LLVM could then lower that to |
Contributor
rust-bors
bot
added
S-waiting-on-bors
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Mar 9, 2026
…op-lower-bound-hermit, r=Mark-Simulacrum tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size LLVM emits a lower bound of 8 for the size parameter to `__rust_alloc` when targeting `x86_64-unknown-hermit`. Since that is also completely valid, relax the lower bound check. I'm not really sure why LLVM is able to infer this - with the same setup targeting `x86_64-unknown-linux-gnu` I also see the lower bound of 0. Not that it's wrong, but I'd be curious to know which codegen options play into this.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 9, 2026
Rollup of 6 pull requests Successful merges: - #153290 (tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size) - #153413 (std: organise `sys::pal::os`) - #139692 (Rustfmt now support use closures) - #153244 (tools: remote-test-server: Add UEFI run support) - #153305 (Adapt codegen test to accept operand bundles) - #153340 (tweak r-a default settings)
Contributor
|
⌛ Testing commit affe609 with merge b772807... Workflow: https://github.com/rust-lang/rust/actions/runs/22844155153 |
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 9, 2026
…und-hermit, r=Mark-Simulacrum tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size LLVM emits a lower bound of 8 for the size parameter to `__rust_alloc` when targeting `x86_64-unknown-hermit`. Since that is also completely valid, relax the lower bound check. I'm not really sure why LLVM is able to infer this - with the same setup targeting `x86_64-unknown-linux-gnu` I also see the lower bound of 0. Not that it's wrong, but I'd be curious to know which codegen options play into this.
Contributor
|
@bors yield |
Contributor
|
Auto build was cancelled. Cancelled workflows: The next pull request likely to be tested is #153590. |
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 9, 2026
Rollup of 6 pull requests Successful merges: - #153290 (tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size) - #153413 (std: organise `sys::pal::os`) - #139692 (Rustfmt now support use closures) - #153244 (tools: remote-test-server: Add UEFI run support) - #153305 (Adapt codegen test to accept operand bundles) - #153340 (tweak r-a default settings)
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 9, 2026
…uwer Rollup of 11 pull requests Successful merges: - #152847 (Test for armv7 `get_unchecked(...)` inlining) - #153290 (tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size) - #153413 (std: organise `sys::pal::os`) - #139692 (Rustfmt now support use closures) - #152800 (Adds recursion limit into FindParamInClause) - #153244 (tools: remote-test-server: Add UEFI run support) - #153305 (Adapt codegen test to accept operand bundles) - #153340 (tweak r-a default settings) - #153509 (Cleanup unused diagnostic emission methods - part 2) - #153527 (Fix LegacyKeyValueFormat report from docker build: ohos) - #153594 (Move some ui tests)
rust-timer
added a commit
that referenced
this pull request
Mar 9, 2026
Rollup merge of #153290 - Gelbpunkt:iter-repeat-n-trivial-drop-lower-bound-hermit, r=Mark-Simulacrum tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size LLVM emits a lower bound of 8 for the size parameter to `__rust_alloc` when targeting `x86_64-unknown-hermit`. Since that is also completely valid, relax the lower bound check. I'm not really sure why LLVM is able to infer this - with the same setup targeting `x86_64-unknown-linux-gnu` I also see the lower bound of 0. Not that it's wrong, but I'd be curious to know which codegen options play into this.
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
4 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.
LLVM emits a lower bound of 8 for the size parameter to
__rust_allocwhen targetingx86_64-unknown-hermit. Since that is also completely valid, relax the lower bound check.I'm not really sure why LLVM is able to infer this - with the same setup targeting
x86_64-unknown-linux-gnuI also see the lower bound of 0. Not that it's wrong, but I'd be curious to know which codegen options play into this.