On Sun, 15 Feb 2026 at 22:09, Rainer Orth <[email protected]> wrote: > > 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.
Nice, that's much simpler and achieves the same opt-out for users who need it. > > 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. That's good news. > > I'll repost and commit the revised patch shortly, adding documentation > to the gcc-16 changes.html and porting_to.html later. Thanks for getting this fixed!
