-
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
riscv64gc-unknown-linux-gnu extern "C"
ABI violates repr(transparent) on unions
#115481
Comments
I think the fix will have to be to treat repr(transparent) unions specially somewhere around here rust/compiler/rustc_target/src/abi/call/riscv.rs Lines 90 to 94 in 1bd0430
|
Cc @msizanoen1 |
@RalfJung I'm afraid that the semantics of |
I have no idea who would know anything about RISC-V calling conventions. 🤷 and no other ABI is failing this test. Basically, when the ABI description says "unions do X", then this should only apply to repr(C) and repr(Rust) unions. A repr(transparent) union must be treated exactly like its non-ZST field. |
…on-ZST member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes rust-lang#115481.
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
I haven't seen the Rust representation before - is the example saying that If so then based on section 18.2 here, I think the first one would be correct, assuming Rust doesn't ever make its tuples opaque https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf @programmerjake helped me with something RISC-V at some point so may know where to look. Or deferring to clang https://clang.godbolt.org/z/rrv5x3eYx |
I honestly don't know what that #115499 has been opened to fix this issue. |
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.
…nion-abi, r=bjorn3 rustc_target/riscv: 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#115481. r? `@RalfJung`
Rollup merge of rust-lang#115499 - msizanoen1:riscv-fix-transparent-union-abi, r=bjorn3 rustc_target/riscv: 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#115481. r? `@RalfJung`
@RalfJung now that this is fixed, is there a CI test to catch regressions? |
There is a test in |
Also see #115609 for another ABI issue that affects riscv (and more). |
Are tier 2 tests run once before release or anything like that? It seems like at least a subset of tests (this one) are important enough that we should raise a red flag if we brake them somehow on any targets. But that doesn't fit well into the tiering structure... |
I'm not aware of any process like that. Part of the point of being tier 2 is not to burden all contributors with keeping the target working, is it? If we do want to accept that burden, we could consider running something like But having this discussion in a closed issue makes little sense. Do you want to open a new issue or Zulip thread for discussing tier 2 target test coverage? |
Awesome! Thanks for the update here |
The types
(i32, f32)
andMaybeUninit<T>
do not have the same ABI, as demonstrated by this testcase:The first is
The second is
Not sure whom to ping for RISC-V issues.
The text was updated successfully, but these errors were encountered: