Hi Richard,
>> If this is worth the complexity or even GCC 16 material I cannot really
>> tell, though.
>
> One might also be able to arrange for int8_t to be mangled the same
> as 'char' even when 'signed char' to avoid the ABI change (but retain
> some of the issues). I'd probably follow what the vendor does, thus
> Studio 12.6 CC, inter-operability with the "platform default" would be
as detailed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450#c24
the situation with Studio 12.6 CC is complicated: the default mode
follows the Sun C++ ABI, only with -std=c++11/14 the output aims to
follow the GNU C++ ABI.
So users of CC are used to ABI issues already ;-) I'd worry more about
interoperability with G++ 15 code. If G++ 16 needs to be ABI-compatible
with that, the suggested -mint8_t-compat design should work, and
implicitly allow to handle CC and clang++ compat just fine if really
need be. My problem is that I have no idea how widespread this issue
really is: as I said, with the exception of the libphobos C++ interop
code it didn't occur anywhere in either a full GCC bootstrap or LLVM
ones (neither 1-stage nor 2-stage).
> my priority, and see to have work arounds for the fallout that happens
> elsewhere ... Does Oracle acknowledge the issue and plan to fix
> in a similar manner?
They do, and intend to change <sys/int_types.h> accordingly after
assessing the possible impact. Even so, with my workaround/hack to
attain full C99 conformance (at least in this regard), one can have both
worlds. If this proves to be too painful in the wild (which I doubt),
it's easy to revert to the original default.
To summarize: the pain for C++ code is real, the possible interop issues
are uncertain.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
