-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Rust thinks u64 and f64 have 4 byte alignment on Linux 32bit #43899
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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 ( |
Uh oh!
There was an error while loading. Please reload this page.
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: