-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
loongarch64-unknown-linux-gnu extern "C"
ABI violates repr(transparent) on unions
#115509
Comments
The loongarch ABI seems to be pretty much exactly like the RISC-V ABI, so I wonder if it would make sense to share some of that code so that bugs like this only have to be fixed once. |
Thanks for the report! The LoongArch ABI is indeed closely modeled after that of RISC-V, so yeah the fix should look similar. @hev should be able to follow up tomorrow. |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
@xen0n I don't think you meant to tag me. Don't know much about rust. |
Thanks for your pointing out. I don't think the types #[repr(transparent)]
pub union MaybeUninit<T> {
/* private fields */
} For types #![feature(rustc_attrs)]
type T = (i32, f32);
#[repr(transparent)]
struct X(T);
#[rustc_abi(debug)]
extern "C" fn test1(_x: T) {}
#[rustc_abi(debug)]
extern "C" fn test2(_x: X) {}
fn main() {} The first is:
The second is:
And it seems that the current ABI of struct T {
int i;
float f;
};
union X {
struct T v;
};
void test1(struct T x) {}
void test2(union X y) {}
int main (int argc, char *argv[])
{
struct T t;
union X x;
t.i = 6339;
t.f = 6338.0;
x.v.i = 6339;
x.v.f = 6338.0;
test1(t);
test2(x);
return 0;
} The first is:
The second is:
|
@heiher: I haven't studied the LoongArch psABI as closely, but from a Rust semantics perspective: |
It's a Rust union, but it doesn't have We promise that Your C example, when translated to Rust, needs |
Thank you for your explanation. Hmm, I'm not familiar with Rust ABI, and it seems to have less relevance to psABI. OK, I will follow the RISC-V patches to fix LoongArch. |
It's the same problem we have on all targets: there is a target ABI that is defined in terms of C types, and now every other language has to figure out how to map their types to C types to then compute the ABI from that. Unfortunately the Rust compiler has no central infrastructure for that (there's no function to "give me the C type that describes the ABI of a given Rust type"), and so each target has to implement that mapping itself, and they are all making similar mistakes... |
@rustbot label +O-loongarch |
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.
…bi, r=bjorn3 rustc_target/loongarch: Fix passing of transparent unions with only one non-ZST member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes rust-lang#115509 r? `@bjorn3`
rustc_target/loongarch: Fix passing of transparent unions with only one non-ZST member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes rust-lang/rust#115509 r? `@bjorn3`
…ne non-ZST member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes rust-lang#115509
…ne non-ZST member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes rust-lang#115509
The types
(i32, f32)
andMaybeUninit<T>
do not have the same ABI, as demonstrated by this testcase:The first is
The second is
RISC-V had the exact same issue, so the fix will likely also be the same.
I couldn't find an O-loongarch label.
Cc'ing the people listed on https://doc.rust-lang.org/rustc/platform-support/loongarch-linux.html
@hev @xiangzhai @zhaixiaojuan @xen0n
The text was updated successfully, but these errors were encountered: