On Thu, Jan 15, 2026 at 7:35 PM Rainer Orth <[email protected]> wrote: > > int8_t is currently defined as char in Solaris <sys/int_types.h> > > /* > * Basic / Extended integer types > * > * The following defines the basic fixed-size integer types. > * > * Implementations are free to typedef them to Standard C integer types or > * extensions that they support. If an implementation does not support one > * of the particular integer data types below, then it should not define the > * typedefs and macros corresponding to that data type. Note that int8_t > * is not defined in -Xs mode on ISAs for which the ABI specifies "char" > * as an unsigned entity because there is no way to define an eight bit > * signed integral. > */ > #if defined(_CHAR_IS_SIGNED) > typedef char int8_t; > #else > #if defined(__STDC__) > typedef signed char int8_t; > #endif > #endif > > and _CHAR_IS_SIGNED defined as 1 in <sys/isa_defs.h>. As has long been > known, this violates C99, 7.18.1.1, Exact-width integer types. > > While this works in general nonetheless, it creates constant trouble for > C++ code as can be seen in PRs libstdc++/113450 and recently > libstdc++/123176, but also in LLVM. > > While Oracle Solaris engineering is amenable to changing int8_t to > signed char, this will take time. However, it proved easy to do so now > using fixincludes. > > This works for a GCC bootstrap just fine with one exception: as > documented in PR d/123509, libdruntime has its own definition of int8_t > which is now inconsistent with GCC's. This leads to some gdc.test and > libphobos testsuite failures, which can easily be fixed with the patch > attached to that PR. I wouldn't consider this a showstopper for GCC 16 > if that patch wouldn't make it to the release. > > However, the failures point to another problem: with this change, the > mangling of > > void func(int8_t); > > changes in C++, creating an ABI break. Fortunately, this isn't seen in > libstdc++, so the impact should be reasonable compared to the constant > trouble the current definition causes for C++. > > Besides, clang already uses > > #define __INT8_TYPE__ signed char > > apparently without problems. > > Bootstrapped on i386-pc-solaris2.11, amd64-pc-solaris2.11, > sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 with only the D > failure described above. > > I've also run 1-stage and bootstrap builds of LLVM main using a patched > GCC 16 as bootstrap compiler on amd64-pc-solaris2.11 and > sparcv9-sun-solaris2.11 without regressions. > > So unless additional concerns come up, I'll commit this patch in a > couple of days.
This probably warrants documenting in gcc-16/changes.html 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). Richard. > Rainer > > -- > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University > > > 2026-01-07 Rainer Orth <[email protected]> > > fixincludes: > PR libstdc++/113450 > PR libstdc++/123176 > * inclhack.def (solaris_int8_t): New fix. > * fixincl.x: Regenerate. > > gcc: > PR libstdc++/113450 > PR libstdc++/123176 > * config/sol2.h (INT8_TYPE): Change to signed char. > (INT_LEAST8_TYPE): Likewise. > (INT_FAST8_TYPE): Likewise. >
