-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
extern "C" fn
on sparc64 targets does not respect repr(transparent)
#115336
Comments
While this particular case might be fixed by having the ABI adjustment logic explicitly unwrap all repr(transparent) wrappers, that will not work in more complicated cases where it is unclear which argument is being wrapped: struct Zst;
#[repr(transparent)]
struct Wrap(Zst, [u8; 0]); A Maybe we have to say that empty arrays do not count as 1-ZST... |
Arguably this is a soundness issue, since unsafe code could rely on |
This affects all arrays, not just empty arrays:
but
|
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-high |
Does this also affect 32-bit SPARCV7 in sparc-unknown-none-elf? |
No, this is specific to sparc64. (Well there might be other ABIs, I didn't check all of them. This PR should tell us once it reaches CI. But this here for |
The only way I see to fix this is to say that the actual presence of ... but that won't be enough for the ZST issue, since we still have the problem that #[repr(transparent)]
struct Wrap((), [u8; 0]); must be ABI-compatible with both of its fields. |
extern "C" fn
on sparc64-unknown-linux-gnu does not respect repr(transparent)extern "C" fn
on sparc64-unknown-linux-gnu and mips64-unknown-linux-gnuabi64 does not respect repr(transparent)
extern "C" fn
on sparc64-unknown-linux-gnu and mips64-unknown-linux-gnuabi64 does not respect repr(transparent)extern "C" fn
on sparc64-unknown-linux-gnu does not respect repr(transparent)
extern "C" fn
on sparc64-unknown-linux-gnu does not respect repr(transparent)extern "C" fn
on sparc64 targets does not respect repr(transparent)
MIPS64 is also affected: #115404. And the non-zero-sized-array case also affects the sparc64-unknown-netbsd, sparc64-unknown-openbsd targets. I reached out to their maintainers via email. |
add rustc_abi(assert_eq) to test some guaranteed or at least highly expected ABI compatibility guarantees This new repr(transparent) test is super useful, it would have found rust-lang#115336 and found rust-lang#115404, rust-lang#115481, rust-lang#115509.
add rustc_abi(assert_eq) to test some guaranteed or at least highly expected ABI compatibility guarantees This new repr(transparent) test is super useful, it would have found rust-lang#115336 and found rust-lang#115404, rust-lang#115481, rust-lang#115509.
add rustc_abi(assert_eq) to test some guaranteed or at least highly expected ABI compatibility guarantees This new repr(transparent) test is super useful, it would have found rust-lang#115336 and found rust-lang#115404, rust-lang#115481, rust-lang#115509.
add rustc_abi(assert_eq) to test some guaranteed or at least highly expected ABI compatibility guarantees This new repr(transparent) test is super useful, it would have found rust-lang/rust#115336 and found rust-lang/rust#115404, rust-lang/rust#115481, rust-lang/rust#115509.
@RalfJung sorry for stupid question. What exactly does mean "using Miri"? I would like to reproduce it on Linux... |
Running |
You don't need to do this any more though, the test in tests/ui/abi/compatibility.rs now works on other targets even without Miri. You can see that some tests are disabled on sparc, e.g. rust/tests/ui/abi/compatibility.rs Lines 269 to 270 in cfb47ca
After enabling them, |
I tried the following code:
When running this with
--target sparc64-unknown-linux-gnu
(using Miri), the first function reports an argument pass mode ofbut the 2nd function reports
I'm not an expert in interpreting PassMode, but
Indirect
andCast
are not compatible, are they?Cc @bjorn3 @eddyb @psumbera
The text was updated successfully, but these errors were encountered: