-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rust thinks u64 and f64 have 4 byte alignment on Linux 32bit #43899
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
Comments
cc @emilio |
According to the i386 System V ABI, u64 and f64 are 4 byte aligned - see Table 2.1 in https://www.uclibc.org/docs/psABI-i386.pdf. |
Yes, but C++ compilers seem to disagree with that, apparently, which causes trouble :( |
C++ doesn't have a stable ABI, it has "whatever gcc and clang decided to do" IIRC. |
Seems to match C in both gcc and clang just fine:
where both output |
Actually even in C++, something like struct Test1 { char c; uint64_t u; }; would have the second field aligned to 4 bytes rather than 8 bytes, as can be found in my bug report to gcc. So the behavior really is, when the type are the first field of a struct, or they are on themselves, they have a different alignment. |
OK, so I don't think this is really a valid issue. It is reasonable that There may be problem when passing So the real problem here is actually a mix of bindgen issue and lack of language support from Rust side when manual alignment ( |
The following code:
with
The generated executable outputs:
which matches neither gcc nor clang.
And this issue seems to block linux32-stylo.
The text was updated successfully, but these errors were encountered: