Skip to content

tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test#159328

Merged
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
DeepeshWR:fix/issue-141649-relax-aarch64-stack-check
Jul 18, 2026
Merged

tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test#159328
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
DeepeshWR:fix/issue-141649-relax-aarch64-stack-check

Conversation

@DeepeshWR

@DeepeshWR DeepeshWR commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

The scoped_two_small_structs test expects sub sp, sp, #48 on
aarch64, which assumes the frame pointer (x29) is saved. Custom targets
that don't set frame-pointer: non-leaf (e.g., OpenEmbedded/Yocto's
aarch64-poky-linux-gnu) omit x29, producing sub sp, sp, #32 instead.

Add -Cforce-frame-pointers=yes to the aarch64 revision so the test
produces consistent codegen regardless of the target's default frame
pointer policy.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 15, 2026
@rustbot

rustbot commented Jul 15, 2026

Copy link
Copy Markdown
Collaborator

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 75 candidates
  • Random selection from 19 candidates

@rustbot

This comment has been minimized.

@jieyouxu

Copy link
Copy Markdown
Member

@rustbot reroll

@rustbot rustbot assigned mati865 and unassigned jieyouxu Jul 15, 2026
@mati865

mati865 commented Jul 15, 2026

Copy link
Copy Markdown
Member

I believe the explanation is a pure hallucination but the test change might be sound (after ammending the other function's comment/assert). Perhaps @nikic or @dianqk could comment on that matter?

@nikic nikic left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The explanation in the PR description is completely nonsense. You're going to have to properly justify where the difference comes from.

View changes since this review

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 15, 2026
@rustbot

rustbot commented Jul 15, 2026

Copy link
Copy Markdown
Collaborator

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@mati865

mati865 commented Jul 15, 2026

Copy link
Copy Markdown
Member

@rustbot author

@RalfJung

RalfJung commented Jul 15, 2026

Copy link
Copy Markdown
Member

Also please note that AI-generated PR descriptions are frowned upon in this project (and generally I think it is good etiquette to get explicit consent from people before confronting them with AI-generated text, or to hide all such text behind a "further LLVM-generated details you can freely skip"). The point of a PR description is for you to describe your motivation and understanding of this change. During the PR review process we expect to interact with a human who has a genuine interest in understanding how to fix this issue properly, and as part of that we expect the PR description to be written by said human.

@dianqk

dianqk commented Jul 15, 2026

Copy link
Copy Markdown
Member

I'm surprised that this is the root cause. LLVM should produce the same result regardless of the optimization level used to build it. Could you explaina bit more?

@DeepeshWR

Copy link
Copy Markdown
Contributor Author

Thank you all for the feedback. I apologize for the AI-generated description, that was a mistake on my part. Let me provide the proper explanation based on my investigation.

Root cause:

The failure occurs in OE-core (OpenEmbedded/Yocto) builds where Rust is compiled against an external system LLVM and tests are run against a custom target aarch64-poky-linux-gnu. This custom target JSON spec does not set "frame-pointer": "non-leaf".

The built-in aarch64-unknown-linux-gnu target in Rust has FramePointer::NonLeaf set (per AAPCS64), which forces x29 to be saved on the stack. This adds 16 bytes to the frame:

  • With frame pointer (rust built-in target): saves x29 + x30 + x19 = sub sp, sp, # 48
  • Without frame pointer (OE custom target): saves x30 + x19 only = sub sp, sp, # 32

I confirmed this by changing FramePointer::NonLeaf to FramePointer::MayOmit in compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_gnu.rs this reproduces #32.

I think both the values are correct.

Please let me know what I need to do now. Whether I can update the commit message with the same fix what we have in this PR or shall I update the testcase with -Cforce-frame-pointers=yes for aarch64 revision.

Let me know which approach you'd prefer and I'll update the PR accordingly.

@nikic

nikic commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

I'd prefer the variant using -Cforce-frame-pointers=yes.

The `scoped_two_small_structs` test expects `sub sp, sp, rust-lang#48` on
aarch64, which assumes the frame pointer (x29) is saved. Custom targets
that don't set `frame-pointer: non-leaf` (e.g., OpenEmbedded/Yocto's
`aarch64-poky-linux-gnu`) omit x29, producing `sub sp, sp, rust-lang#32` instead.

Add `-Cforce-frame-pointers=yes` to the aarch64 revision so the test
produces consistent codegen regardless of the target's default frame
pointer policy.

Signed-off-by: Deepesh Varatharajan <[email protected]>
@DeepeshWR
DeepeshWR force-pushed the fix/issue-141649-relax-aarch64-stack-check branch from 0cb43cc to 9e0664a Compare July 16, 2026 14:52
@rustbot

rustbot commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

⚠️ Warning ⚠️

  • There are issue links (such as #123) in the commit messages of the following commits.
    Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.

@DeepeshWR DeepeshWR changed the title tests/assembly-llvm: relax aarch64 stack size check in issue-141649 tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test Jul 16, 2026
@DeepeshWR

Copy link
Copy Markdown
Contributor Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 16, 2026
@DeepeshWR
DeepeshWR requested a review from nikic July 17, 2026 02:01

@mati865 mati865 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rust-bors

rust-bors Bot commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 9e0664a has been approved by mati865

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 18, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 18, 2026
…arch64-stack-check, r=mati865

tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test

The `scoped_two_small_structs` test expects `sub sp, sp, rust-lang#48` on
aarch64, which assumes the frame pointer (x29) is saved. Custom targets
that don't set `frame-pointer: non-leaf` (e.g., OpenEmbedded/Yocto's
`aarch64-poky-linux-gnu`) omit x29, producing `sub sp, sp, rust-lang#32` instead.

Add `-Cforce-frame-pointers=yes` to the aarch64 revision so the test
produces consistent codegen regardless of the target's default frame
pointer policy.
rust-bors Bot pushed a commit that referenced this pull request Jul 18, 2026
…uwer

Rollup of 5 pull requests

Successful merges:

 - #159189 (Account for type alias projections in E0308 "expected/found" shortening logic)
 - #158545 (Move `std::io::read_to_string` to `alloc::io`)
 - #159328 (tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test)
 - #159470 (Fix string indexing in diagnostic format strings)
 - #159500 (Move compiletest CLI parsing to `cli.rs`)
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 18, 2026
…arch64-stack-check, r=mati865

tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test

The `scoped_two_small_structs` test expects `sub sp, sp, rust-lang#48` on
aarch64, which assumes the frame pointer (x29) is saved. Custom targets
that don't set `frame-pointer: non-leaf` (e.g., OpenEmbedded/Yocto's
`aarch64-poky-linux-gnu`) omit x29, producing `sub sp, sp, rust-lang#32` instead.

Add `-Cforce-frame-pointers=yes` to the aarch64 revision so the test
produces consistent codegen regardless of the target's default frame
pointer policy.
rust-bors Bot pushed a commit that referenced this pull request Jul 18, 2026
…uwer

Rollup of 5 pull requests

Successful merges:

 - #159467 (Add explicit `Iterator::count` impl for `str::EncodeUtf16`)
 - #158545 (Move `std::io::read_to_string` to `alloc::io`)
 - #159328 (tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test)
 - #159470 (Fix string indexing in diagnostic format strings)
 - #159500 (Move compiletest CLI parsing to `cli.rs`)
rust-bors Bot pushed a commit that referenced this pull request Jul 18, 2026
…uwer

Rollup of 8 pull requests

Successful merges:

 - #159425 (Windows: add context when opening NUL for child stdio fails)
 - #159467 (Add explicit `Iterator::count` impl for `str::EncodeUtf16`)
 - #157860 (Move rustdoc run-make tests into new `tests/run-make/rustdoc/`)
 - #158545 (Move `std::io::read_to_string` to `alloc::io`)
 - #159328 (tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test)
 - #159459 (Detect when trait bound requires closure to return itself)
 - #159470 (Fix string indexing in diagnostic format strings)
 - #159500 (Move compiletest CLI parsing to `cli.rs`)
@rust-bors
rust-bors Bot merged commit 823b135 into rust-lang:main Jul 18, 2026
13 checks passed
@rustbot rustbot added this to the 1.99.0 milestone Jul 18, 2026
rust-timer added a commit that referenced this pull request Jul 18, 2026
Rollup merge of #159328 - DeepeshWR:fix/issue-141649-relax-aarch64-stack-check, r=mati865

tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test

The `scoped_two_small_structs` test expects `sub sp, sp, #48` on
aarch64, which assumes the frame pointer (x29) is saved. Custom targets
that don't set `frame-pointer: non-leaf` (e.g., OpenEmbedded/Yocto's
`aarch64-poky-linux-gnu`) omit x29, producing `sub sp, sp, #32` instead.

Add `-Cforce-frame-pointers=yes` to the aarch64 revision so the test
produces consistent codegen regardless of the target's default frame
pointer policy.
github-actions Bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Jul 20, 2026
…uwer

Rollup of 8 pull requests

Successful merges:

 - rust-lang/rust#159425 (Windows: add context when opening NUL for child stdio fails)
 - rust-lang/rust#159467 (Add explicit `Iterator::count` impl for `str::EncodeUtf16`)
 - rust-lang/rust#157860 (Move rustdoc run-make tests into new `tests/run-make/rustdoc/`)
 - rust-lang/rust#158545 (Move `std::io::read_to_string` to `alloc::io`)
 - rust-lang/rust#159328 (tests/assembly-llvm: pin frame pointer in issue-141649 aarch64 test)
 - rust-lang/rust#159459 (Detect when trait bound requires closure to return itself)
 - rust-lang/rust#159470 (Fix string indexing in diagnostic format strings)
 - rust-lang/rust#159500 (Move compiletest CLI parsing to `cli.rs`)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants