4 ms·

__int128 is not a C type, it's a proprietary extension of GCC and clang (among others).

by jupp0r 3y ago

shikon7 3y ago
Still it is mentioned in the ABI specification, although as an optional type.
raverbashing 3y ago
Thank you compiler developers (this time) for giving resources that people use and find useful (Still weird why would LLVM not align it to 16 bytes though)
kryptiskt 3y ago
It's a C type, it's not in the standard, but there are a lot of types that aren't in the standard. And of course, it would have been in the standard long ago if they hadn't made a terrible mistake in C99 with intmax_t[0]. [0] A Special Kind of Hell - intmax_t in C and C++: https://thephd.dev/intmax_t-hell-c++-c https://thephd.dev/intmax_t-hell-c++-c
stephencanon 3y ago
_BitInt(128) is a C(23) type and has all of the same problems plus a few others.
- tmgross 3y ago
  Elaborating on the problems - _BitInt(128) has an alignment of 8, meaning that C's _BitInt(128) and __int128 are incompatible, similar to the Rust-C incompatibility that was just fixed :(. https://groups.google.com/g/x86-64-abi/c/-JeR9HgUU20 https://groups.google.com/g/x86-64-abi/c/-JeR9HgUU20
  - stephencanon 3y ago
    It's actually worse than that; from what I can piece together of the history: 1. the people at Intel who originally implemented `_BitInt()` made `_BitInt(128)` eight-byte aligned 2. the x86_64 psABI document was updated to agree with that 3. it was implemented in clang in such a way that it also made `_BitInt(128)` eight-byte aligned on arm64 ... 4. ... but the AAPCS says that it's sixteen-byte aligned 5. ... and maybe the x86_64 psABI is going to change to say that it's sixteen byte aligned after-all. So--as of a month ago when I was studying this because we're in the middle of enabling `[U]Int128` in Swift--_BitInt(128) didn't agree with __int128[_t] on either platform, and that's definitely a bug on arm64, and, although it behaves as documented on x86_64, that also might change.

__int128 is not a C type, it's a proprietary extension of GCC and clang (among others).

by jupp0r 3y ago

__int128 is not a C type, it's a proprietary extension of GCC and clang (among others).

shikon7 3y ago

Still it is mentioned in the ABI specification, although as an optional type.

raverbashing 3y ago

Thank you compiler developers (this time) for giving resources that people use and find useful (Still weird why would LLVM not align it to 16 bytes though)

kryptiskt 3y ago

It's a C type, it's not in the standard, but there are a lot of types that aren't in the standard. And of course, it would have been in the standard long ago if they hadn't made a terrible mistake in C99 with intmax_t[0]. [0] A Special Kind of Hell - intmax_t in C and C++: https://thephd.dev/intmax_t-hell-c++-c https://thephd.dev/intmax_t-hell-c++-c

stephencanon 3y ago

_BitInt(128) is a C(23) type and has all of the same problems plus a few others.

tmgross 3y ago
Elaborating on the problems - _BitInt(128) has an alignment of 8, meaning that C's _BitInt(128) and __int128 are incompatible, similar to the Rust-C incompatibility that was just fixed :(. https://groups.google.com/g/x86-64-abi/c/-JeR9HgUU20 https://groups.google.com/g/x86-64-abi/c/-JeR9HgUU20
- stephencanon 3y ago
  It's actually worse than that; from what I can piece together of the history: 1. the people at Intel who originally implemented `_BitInt()` made `_BitInt(128)` eight-byte aligned 2. the x86_64 psABI document was updated to agree with that 3. it was implemented in clang in such a way that it also made `_BitInt(128)` eight-byte aligned on arm64 ... 4. ... but the AAPCS says that it's sixteen-byte aligned 5. ... and maybe the x86_64 psABI is going to change to say that it's sixteen byte aligned after-all. So--as of a month ago when I was studying this because we're in the middle of enabling `[U]Int128` in Swift--_BitInt(128) didn't agree with __int128[_t] on either platform, and that's definitely a bug on arm64, and, although it behaves as documented on x86_64, that also might change.