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.
>
> 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).
I've now checked with the Solaris engineers and did some more testing
myself. I've come to the conclusion that the -mint8_t-compat route is
overkill. Instead, I'll just wrap the C99-compatible typedefs created
by fixincludes in #if !defined (_LEGACY_INT8_T)/#endif so users who
really run into the incompatiblity have a way back to how things were
before. The name has been agreed upon with the Solaris engineers, so
when the same change is made to the Solaris headers, the user-visible
situation remains unchanged.
Changing gcc's internal definition of int8_t etc (INT8_TYPE and friends)
isn' really necessary, after all: unlike e.g. glibc-based systems that
use __INT8_TYPE__ in their headers to guarantee that the ideas gcc and
glibc have about int8_t match, this isn't an issue on Solaris since the
system headers don't use __INT8_TYPE__ at all.
I've run make check with the fixed gcc, adding -D_LEGACY_INT8_T to the
test options, and only a few failures occured:
* The expected reocurrences of PRs 123176 and 123509, and
* two failures due to the int8_t/__INT8_TYPE__ mismatch:
FAIL: gcc.dg/c99-stdint-5.c (test for excess errors)
FAIL: gcc.dg/c99-stdint-6.c (test for excess errors)
Besides, Petr Sumbera from Oracle built Solaris Userland
(https://github.com/oracle/solaris-userland) with a patched gcc: only a
single instance of the name mangling difference turned up, so it's
pretty clear that issues will be rare in the wild.
I'll repost and commit the revised patch shortly, adding documentation
to the gcc-16 changes.html and porting_to.html later.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
