Repository navigation
extern "C" fn on mips64 targets does not respect repr(transparent) #115404
Description
This is the MIPS version of #115336: on the target mips64-unknown-linux-gnuabi64, all arrays and some tuple types like (i32, f32, i64, f64) have a different ABI when being wrapped in repr(transparent) wrappers, and hence this fails the test I added in #115372.
For instance for [u8; 2], the PassMode becomes
mode: Indirect {
attrs: ArgAttributes {
regular: NoAlias | NoCapture | NonNull | NoUndef,
arg_ext: None,
pointee_size: Size(2 bytes),
pointee_align: Some(
Align(1 bytes),
),
},
extra_attrs: None,
on_stack: false,
},
But for Wrapper<[u8; 2]> it becomes
mode: Cast(
CastTarget {
prefix: [
None,
None,
None,
None,
None,
None,
None,
None,
],
rest: Uniform {
unit: Reg {
kind: Integer,
size: Size(8 bytes),
},
total: Size(2 bytes),
},
attrs: ArgAttributes {
regular: (empty),
arg_ext: None,
pointee_size: Size(0 bytes),
pointee_align: None,
},
},
false,
),
This also affects mips64el-unknown-linux-gnuabi64, mips64-openwrt-linux-musl, mips64-unknown-linux-muslabi64, mips64el-unknown-linux-muslabi64
Cc @Itus-Shield (listed as maintainer for the openwrt target)
Activity
RalfJung commentedon Aug 31, 2023
As per #115238, all affected targets are tier 3 targets.
apiraino commentedon Sep 4, 2023
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-low
RalfJung commentedon Sep 6, 2023
Here's another example of a
repr(transparent)violation on mips64, orthogonal to the first:Tgets passed in 3 float registers, butWrap<T>is passed in 3 integer registers. The problem is that this search here doesn't recurse into fields of nested structs.(I don't know what the C ABI says for this target, i.e. whether it is truly only double fields that appear directly in the struct type that should be passed in registers, and any doubles in nested fields-of-fields really should be ignored. So there might also be an ABI incompatibility with C here.)
RalfJung commentedon Sep 8, 2023
I'm also seeing this target use
PassMode::Castfor unsized types... that makes no sense, right?bjorn3 commentedon Sep 8, 2023
Yeah, unsized args should always be passed as PassMode::Indirect with on_stack=false.
Auto merge of #115372 - RalfJung:abi-assert-eq, r=davidtwco
RalfJung commentedon Aug 30, 2026
There are more cases where mips is wrong:
With that declaration,
ReprC<f32>behaves incorrectly when wrapped in a repr(transparent) wrapper. See the test in #161991.But apparently nobody cares about MIPS enough to fix critical ABI issues. It's been 3 years. All the other targets got fixed. MIPS is clearly unmaintained and broken. Even tier 3 targets require a target maintainer, so IMO MIPS should be removed.
beetrees commentedon Aug 30, 2026
While
mips64{,el}-unknown-linux-gnuabi64don't have target maintainers, several other 64-bit MIPS target do. Specifically:This issue has been on my TODO pile for a while, so I'll take a look now: @rustbot claim
add reproducer for MIPS transparent wrapper ABI issues
Gelbpunkt commentedon Aug 30, 2026
Thanks for the ping. Generally speaking I'm happy to look into MIPS ABI issues, but I wasn't listed as a maintainer for the target at the time that this issue was opened (and it seems like some people only look at the -gnu targets for finding maintainers). Please feel free to ping me on MIPS ABI issues. I make use of Rust on mips64 quite a bit, but haven't encountered any noticeable issues so far beyond what I've already fixed previously, so I did not have issues like this one on my radar.
folkertdev commentedon Aug 30, 2026
We've also had good success with fixing a variety of Clang/LLVM bugs in LLVM 23 and LLVM 24, and the targets are straightforward to cross compile to and run with qemu (which cannot be said for some other targets that we have, that also have glaring ABI issues).
So, the situation seems fine to me actually, and this bug looks straightforward to fix (especially now that we have decent testing infrastructure). Just a matter of nerdsniping the right person.
RalfJung commentedon Aug 30, 2026
In terms of repr(transparent) issues, mips64 is the only target I am aware of that has glaring issues. And we've had the cross-testing infrastructure for that for 3 years, that's how I found these problems in the first place.
But, if there are people caring about the target and willing to look into it, it's all good. :)
When I opened the issue indeed there wasn't anyone to ping for most of the mips targets.