Hi Jonathan,
> On Fri, 16 Jan 2026 at 07:11, Richard Biener wrote:
>> Does this mean that ABI-wise non-fixincluded and fixincluded
>> versions do not inter-operate? I wonder if it makes sense
>> to diagnose int8_t versions that do not adhere to the (updated)
>> ABI then (not sure if there's a suitable backend hook).
>
> I can imagine two main sources of interop problems.
>
> The first would be limited to templates and overloaded functions that
> are defined for only one of char/signed char, or are defined for both
> but with incompatible semantics.
>
> class String {
> void append(char c); // append c to string
> void append(signed char n); // append N spaces to string
> };
>
> This seems unlikely to cause many problem in practice, because if the
> API above used int8_t instead of signed char then it would not compile
> on Solaris today (it would be a duplicate definition of the same
> function). If somebody really defined the stupid API above, their code
> might change meaning after this change if they do
> str.append((int8_t)'x') because it would start to all the other
> overload.
same here: if users do weird things, they get what they pay for.
Besides, with the proposed -mint8_t-compat design, they could always get
back to the previous default.
> The other source of problems would be where int8_t has been used in a
> function declaration or an explicit specialization of a template,
> where the mangled name would now change. This could cause linker
> errors, but I think it's unlikely to cause silent changes in
> behaviour.
>
> Given a function declared as foo(int8_t) the mangled name would change
> from _Z3fooc to _X3fooa, so if the caller of the function and the
> definition of the function use different versions of GCC, it wouldn't
> match. I don't /think/ int8_t gets used in public APIs this way very
> often. I could be wrong.
True: one would probably have to rebuild a large body of code to find if
there any issues. My (admittedly limited) initial experience with GCC
and LLVM seems to suggest that this is not too bad.
As usual for an ABI break, we could simply tell users to recompile their
code, but that's clearly not an option if they need to interlink with
binary-only libraries.
> I'm not *hugely* concerned that these would be big problems in
> practice. A new option like -mint8_t-compat would offer a solution for
> anybody who really was affected (and if it turns out to be a big
> problem, we could make that the default, at least until the Solaris
> compiler makes a similar change).
Just my thought. Besides, Studio 12.6 is in deep maintenance mode:
there will only be the most critical fixes, and I doubt this is one of
them. It also seems to me that Studio cc/CC doesn't have an internal
idea of e.g. int8_t, unlike gcc/clang.
I've not yet checked, but as clang already has int8_t as signed char:
$ clang -dD -E - < /dev/null|grep __INT8_TYPE__
#define __INT8_TYPE__ signed char
there would already be the same interop problem we're discussing here,
without anyone having noticed. However, clang is less widely used on
Solaris, so that may be part of the reason.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
