Whether we have __int128 support in the compiler affects the resulting
library ABI, but there are a few places where we currently don't
reflect this.
Firstly, __config dynamically detects _LIBCPP_HAS_NO_INT128 in the
public headers. This could generate inconsistent results with how the
library was built, if the user uses a compiler with __int128 support
while the library was build without. This change moves
_LIBCPP_HAS_NO_INT128 to __config_site and introduces an option
LIBCXX_USE_INT128 that allows toggling __int128 usage even if it is
available in the build compiler.
Secondly, we add LIBCXX_USE_INT128 to the abi affecting properties for
abilists and update the extension of the existing lists. This will allow
us to generate consistent abis lists on platforms where some compilers
may support __int128 and others don't (e.g. AIX).
I don't think we should allow this to be set explicitly during CMake configuration. If it's an ABI affecting property of the compiler, I believe we should just detect it and set/unset it unconditionally.
I can't imagine building libc++ with one compiler and using it with a compiler so different that it would differ in whether it supports int128. For example, compiling libc++ with a version of Clang and using the headers with a different version of Clang clearly works, however I wouldn't dare ship a library compiled with e.g. GCC to my users. Not saying it won't work, but it seems like living on the edge -- enough that I don't think it's worth supporting. WDYT?