[beetrees]

This avoids using the LLVM va_arg instruction. AFAICT LLVM's implementation currently miscompiles the va_arg instruction for f64 (and needlessly aligns the pointer that is guaranteed to be aligned for i32 and i64) - this PR matches GCC (checked by comparing the assembly).

Ping target maintainers: @glaubitz @ricky26 @knickish

r? @folkertdev

[folkertdev]

As discussed in #rustc-codegen-gcc > ABI of m68k, there are several ABIs for m68k and the current rust targets don't match GCC overall, so I'm not sure it should be the reference for the rustc implementation.

Hopefully the target maintainers can shine a light on the situation?

[glaubitz]

As discussed in #rustc-codegen-gcc > ABI of m68k, there are several ABIs for m68k and the current rust targets don't match GCC overall, so I'm not sure it should be the reference for the rustc implementation.

Hopefully the target maintainers can shine a light on the situation?

There is actually just one official SysV m68k ELF ABI.

Linux is off-standard and I'm working on changing that as explained on the Debian Wiki.

NetBSD/ELF is using the proper ABI, Linux isn't.

[folkertdev]

So to be clear, you would support rust matching GCC's va_arg right now? And the implementation here matches the desired ABI as far as you can tell?

[beetrees]

For the types Rust currently supports (f64, i32/u32, i64/u64 and equivalent) the implementation in this PR matches (AFAICT) how both GCC and Clang currently pass arguments (LLVM/Clang's va_arg doesn't match its own argument passing) and the SysV m68k ELF ABI mentioned above (i.e. 4 byte stack slots with no extra alignment required), so this implementation should be forwards compatible with any changes to bring the ABI closer to the SysV standard.

[rustbot]

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.