%x is clearly not align 16 as we indicate. This is unsound.
@rustbot label I-unsound A-ffi
This issue is somewhat similar to #80127. The fix for that issue, #112157, made this problem worse by causing Rust and byval alignments to differ in more cases. (That change is correct, because the Rust and byval alignment must differ to satisfy the ABI. It just uncovered this issue in more cases.)
This is also similar to #112480. However, unlike that one, this issue is practical (and easy) to fix. byval pointers are not exposed to Rust code, so we can just make a copy of the argument into a higher-aligned alloca, without breaking Rust semantics.
In fact, we already do this in the reverse situation, when the Rust alignment is lower than the byval alignment (https://godbolt.org/z/Ksxoo3aja):
I tried this code:
I expected to see this happen: Alignment requirements are upheld.
Instead, this happened: https://godbolt.org/z/ej65d5hsv
%x
is clearly notalign 16
as we indicate. This is unsound.@rustbot label I-unsound A-ffi
This issue is somewhat similar to #80127. The fix for that issue, #112157, made this problem worse by causing Rust and
byval
alignments to differ in more cases. (That change is correct, because the Rust andbyval
alignment must differ to satisfy the ABI. It just uncovered this issue in more cases.)This is also similar to #112480. However, unlike that one, this issue is practical (and easy) to fix.
byval
pointers are not exposed to Rust code, so we can just make a copy of the argument into a higher-aligned alloca, without breaking Rust semantics.In fact, we already do this in the reverse situation, when the Rust alignment is lower than the
byval
alignment (https://godbolt.org/z/Ksxoo3aja):Meta
rustc --version --verbose
: