Several platforms still have incorrectly aligned u128/i128

[beetrees]

Edit: This issue has been fixed in LLVM 20 and in the rustc target specifications (meaning rustc-emitted allocations will now use the correct alignment, and std::mem::align_of::<u128>() will give the correct result). The only thing remaining is for rustc to update to LLVM 20 in case LLVM itself uses the alignment in a way that affects the ABI.

Original description

I tried this code:

fn main() {
    dbg!(std::mem::align_of::<u128>());
}

I expected to see this happen: The printed alignment to match the alignment used for __int128_t by GCC and Clang.

Instead, this happened: On 64-bit PowerPC, 64-bit SPARC and 64-bit MIPS, Rust thinks the alignment is 8 whereas GCC and Clang think the alignment is 16. The PowerPC 64-bit ABI specifications (both ELFv1 and ELFv2) agree with GCC and Clang (I'm not aware of any specification for 128-bit integers on SPARC64 or MIPS64, but GCC/Clang's behaviour seems to be the de-facto standard). This is because the LLVM data layout for the affected platforms doesn't correctly specify the alignment. This is the same as #54341 but on different architectures (cc rust-lang/lang-team#255). I initially discovered this when running abi-cafe on PowerPC64 to test #128643. I've filed an LLVM bug at llvm/llvm-project#102783.

Meta

rustc --version --verbose:

rustc 1.82.0-nightly (ca5d25e2c 2024-08-09)
binary: rustc
commit-hash: ca5d25e2c41f5a6b4ce65c681bf2f94c7ead1f14
commit-date: 2024-08-09
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0

[beetrees]

@rustbot label +A-abi +A-ffi +A-llvm +T-compiler

[tgross35]

For reference: https://godbolt.org/z/frcKoE6vn

[beetrees]

Fixed in LLVM 20.

@rustbot label +llvm-fixed-upstream

[bjorn3]

We still need to change the data-layout on the rustc side.

[beetrees]

The data layouts have now all been updated in rustc (SPARC, MIPS, PowerPC).

[tgross35]

What else is left to do for this issue?

[tgross35]

Windows has an issue with its i128 ABI, I don't think it's tracked anywhere (outside of an issue in the lang team repo) so maybe this issue could be repurposed.

[beetrees]

This issue is just waiting on LLVM 20 now. Regarding the Windows issue: I'm guessing your referring to rust-lang/lang-team#255 (comment)? It's not really the same issue as this (alignment mismatch vs return ABI mismatch), so it seems better to open a separate rust-lang/rust issue about it so it can be tracked separately. Both x86_64-pc-windows-gnu and x86_64-pc-windows-msvc targets on Clang and MinGW GCC seem to agree that i128 is returned in xmm0, and compiler-builtins even has a special hack to use make sure u128/i128 are returned in xmm0 so that the builtins ABI is what LLVM expects.

[tgross35]

Right, I forgot we are waiting on a LLVM upgrade. Regarding Windows, Wesley thinks that Clang is in the wrong here on the MSVC targets https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/MSVC.20.60f16.60.20and.20.60f128.60.20ABI/near/480542167.

[tgross35]

Opened #134288 for the Windows issue.

[RalfJung]

This issue is just waiting on LLVM 20 now.

If that is the accepted consensus, would be nice to update the issue description. :)

[beetrees]

While updating the issue description, I've realised that the updates to the target specs that have already been merged into rustc means that rustc itself already uses the correct alignment and this issue is more or less fixed, thanks to all the work that was put into handling the x86-64 128-bit integer alignment update. The only exception to this is if LLVM itself uses the alignment in a way that affects the ABI; I haven't had the time to check whether this is the case or not yet but if LLVM doesn't use the alignment in that way this issue can be closed (otherwise it can be closed once rustc uses LLVM 20).

[beetrees]

LLVM 20 has been merged in #135763.