Hacker News Reader

Comment by jupp0r | Hacker News Reader

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

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

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

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

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.

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

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)

Reply on news.ycombinator.com