Skip to content

Conversation

@folkertdev
Copy link
Contributor

tracking issue: #44930

Continuing from #150094, the more annoying cases remain. These are mostly very niche targets without Clang va_arg implementations, and so it might just be easier to defer to LLVM instead of us getting the ABI subtly wrong. That does mean we cannot stabilize c-variadic on those targets I think.

Alternatively we could ask target maintainers to contribute an implementation. I'd honestly prefer they make that change to LVM though (likely by just using CodeGen::emitVoidPtrVAArg) that we can mirror.

r? @workingjubilee

@folkertdev folkertdev added the F-c_variadic `#![feature(c_variadic)]` label Jan 8, 2026
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 8, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 8, 2026

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

Comment on lines -1076 to +1089
Arch::LoongArch32 => emit_ptr_va_arg(
Arch::RiscV32 if target.abi == Abi::Ilp32e => {
// FIXME: clang manually adjusts the alignment for this ABI. It notes:
//
// > To be compatible with GCC's behaviors, we force arguments with
// > 2×XLEN-bit alignment and size at most 2×XLEN bits like `long long`,
// > `unsigned long long` and `double` to have 4-byte alignment. This
// > behavior may be changed when RV32E/ILP32E is ratified.
bx.va_arg(addr.immediate(), bx.cx.layout_of(target_ty).llvm_type(bx.cx))
}
Arch::RiscV32 | Arch::LoongArch32 => emit_ptr_va_arg(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @almindor @dkhayes117 @romancardenas @MabezDev @jessebraham @rmsyn

This special case for Ilp32e is unfortunate. Can any of you shine any light on this?

Comment on lines +1178 to +1177
Arch::Sparc64 => emit_ptr_va_arg(
bx,
addr,
target_ty,
if target_ty_size > 2 * 8 { PassMode::Indirect } else { PassMode::Direct },
SlotSize::Bytes8,
AllowHigherAlign::Yes,
ForceRightAdjust::No,
),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @jonathanpallant

apparently there is no actual sparc64 rust target? just sparc is handled below.

Copy link
Member

Choose a reason for hiding this comment

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

sparc64-unknown-linux-gnu?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh right that does exist but does not get a page here

https://doc.rust-lang.org/beta/rustc/platform-support.html

and therefore apparently does not have a target maintainer?

Copy link
Member

Choose a reason for hiding this comment

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

Correct, afaik.

Copy link
Member

@workingjubilee workingjubilee Jan 26, 2026

Choose a reason for hiding this comment

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

Oh, also more specifically: "sparcv9" is a somewhat obfuscated (or "more correct", if you prefer) way of saying "sparc64": https://doc.rust-lang.org/nightly/rustc/platform-support/solaris.html

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, sparcv9-sun-solaris is 64 bit. Is there anything we should check?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

github renders weirdly, there is some context in #150831 (review)

Arch::SpirV => bug!("spirv does not support c-variadic functions"),

Arch::Mips | Arch::Mips32r6 | Arch::Mips64 | Arch::Mips64r6 => {
// FIXME: port MipsTargetLowering::lowerVAARG.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @Gelbpunkt

Do you have any insights here? Perhaps we could make a PR to LLVM to clean things up?

Comment on lines +1195 to +1189
Arch::Sparc | Arch::Avr | Arch::M68k | Arch::Msp430 => {
// Clang uses the LLVM implementation for these architectures.
bx.va_arg(addr.immediate(), bx.cx.layout_of(target_ty).llvm_type(bx.cx))
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rust-log-analyzer

This comment has been minimized.

@folkertdev folkertdev marked this pull request as ready for review January 9, 2026 21:08
@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 Jan 9, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 15, 2026

☔ The latest upstream changes (presumably #151144) made this pull request unmergeable. Please resolve the merge conflicts.

@rustbot
Copy link
Collaborator

rustbot commented Jan 16, 2026

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Copy link
Contributor Author

@folkertdev folkertdev left a comment

Choose a reason for hiding this comment

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

Hello target maintainers, just making sure that you all see this. Overall we're just copying what clang does, but let us know if there is anything that doesn't look right or if you have useful background information. Otherwise maybe just thumbs-up the message to indicate that it looks good.

Some context you might be missing: I'm trying to stabilize c-variadic function definitions in rust. Historically, just relying on LLVM has been fragile, so we're replicating what clang does in this file. Doing (some of) our own codegen means we can make stronger promises about the exact behavior.

By making this match exhaustive, we'll know that we've at least considered all of the different targets.

View changes since this review

Comment on lines -1076 to +1089
Arch::LoongArch32 => emit_ptr_va_arg(
Arch::RiscV32 if target.abi == Abi::Ilp32e => {
// FIXME: clang manually adjusts the alignment for this ABI. It notes:
//
// > To be compatible with GCC's behaviors, we force arguments with
// > 2×XLEN-bit alignment and size at most 2×XLEN bits like `long long`,
// > `unsigned long long` and `double` to have 4-byte alignment. This
// > behavior may be changed when RV32E/ILP32E is ratified.
bx.va_arg(addr.immediate(), bx.cx.layout_of(target_ty).llvm_type(bx.cx))
}
Arch::RiscV32 | Arch::LoongArch32 => emit_ptr_va_arg(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @almindor @dkhayes117 @romancardenas @MabezDev @jessebraham @rmsyn

This special case for Ilp32e is unfortunate. Can any of you shine any light on this?

Arch::SpirV => bug!("spirv does not support c-variadic functions"),

Arch::Mips | Arch::Mips32r6 | Arch::Mips64 | Arch::Mips64r6 => {
// FIXME: port MipsTargetLowering::lowerVAARG.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @Gelbpunkt

Do you have any insights here? Perhaps we could make a PR to LLVM to clean things up?

Comment on lines +1178 to +1177
Arch::Sparc64 => emit_ptr_va_arg(
bx,
addr,
target_ty,
if target_ty_size > 2 * 8 { PassMode::Indirect } else { PassMode::Direct },
SlotSize::Bytes8,
AllowHigherAlign::Yes,
ForceRightAdjust::No,
),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @jonathanpallant

apparently there is no actual sparc64 rust target? just sparc is handled below.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. F-c_variadic `#![feature(c_variadic)]` 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants