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.
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.
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).
