uname: x86_64 GNU/Linux
Causes things like CMPXCHG16B to segfault.
https://play.rust-lang.org/?gist=2c9d71615fe1839d3368b0a4364af9cd&version=nightly
P.S. @aweinstock314 it works _sometimes_ :D
spacejam
All 6 comments
For comparison, u64 is also not naturally aligned on (most? some?) 32 bit platforms. I don't see a strong reason to increase the alignment for {i,u}128 if the only use cases for 16 byte alignment are obscure instructions accessed via intrinsics and inline assembly. Niche use cases that need higher alignment can and should use repr(align(N)).
hanna-kruppe
on 2 Jan 2018
We don't actually have a say in this, so even if we wanted to do it, it would be wrong.
The target ABI specifications decide what kind of alignment should be used, and choosing something else would make us incompatible with C and might not even be supported by LLVM.
eddyb
on 2 Jan 2018
cc @alexcrichton @nagisa Can we just close this? As per my previous comment, it's not a bug IMO.
eddyb
on 2 Jan 2018
might not even be supported by LLVM.
Under-aligned loads and stores, at least, must be supported (e.g., for repr(packed)). But otherwise you're completely right.
hanna-kruppe
on 2 Jan 2018
@rkruppe I mean changing the alignment in the data layout, in order to still use LLVM's i128.
eddyb
on 2 Jan 2018
I feel like we should close, yeah. The alignment here is dictated by the platform, not our whim. Although it is in our power to do at least stack allocas with increased alignment, I feel like that should be left up to user.
nagisa
on 2 Jan 2018
Related issues
dtolnay
路
3Comments
tikue
路
3Comments
pedrohjordao
路
3Comments
cuviper
路
3Comments
lambda-fairy
路
3Comments
Most helpful comment
We don't actually have a say in this, so even if we wanted to do it, it would be wrong.
The target ABI specifications decide what kind of alignment should be used, and choosing something else would make us incompatible with C and might not even be supported by LLVM.