Closed yuyichao closed 3 months ago
Will #22649 fix this?
Not afaict. The llvm pr might though.
The llvm PR got reverted in https://github.com/llvm-mirror/llvm/commit/8c54b816e554ff9f9a75ec8a1d50198d2bfd9633.
I don't think this is a 1.0-blocking issue.
Note that fixing this will be breaking.
Note that fixing this will be breaking.
Only if we declare struct layout to be stable in 1.0, which I don't think we should do.
What do you mean? The structure layout (and size) is a user observable API so changing that is breaking.
Yes, but what we promise not to break is up to us.
Well, that's an API that people needs to rely on so we'll have to call that a breaking change, especially for isbits
layout.
Whether that can be an API breakage exception for 1.0 is another issue.
AFAIK, LLVM 18 fixed this?
We probably should add tests then?
I found quite nice to explain the situation. https://blog.rust-lang.org/2024/03/30/i128-layout-update.html
A recent discourse post just reminds me about this....
(Or in general, any C->LLVM mapping that requires explicit padding.)
The alignment for
Int128
on x64 is currently8
in julia and LLVM. However, AFAIK, it should be16
in order to match the C ABI. Fixing this may require adding explicit padding fields when we declare the LLVM struct in the same way clang does it. The hard part is to fix all the use ofgep
on a struct in codegen to use the actual field index including the padding field rather than the julia field index.