[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
>> (In reply to Jonathan Wakely from comment #1)
>>> I assume that int8_t is char on Solaris, rather than signed char?
>>
>> This actually violates the C and C++ standards, which require that intN_t is a
>> signed integer type, and C 6.2.5 says "There are five standard signed integer
>> types, designated as signed char, short int, int, long int, and long long int."
>> So char isn't allowed, it should be signed char.
>
> I've done some digging now: <inttypes.h>/<sys/int_types.h> were
> introduced into Solaris 2.6 (the file dates from Jul 16 1997), way
> before the C99 standard was finalized.

Further research has uncovered some interesting facts:

* Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386
  psABI (4th Edition, 1997) specify int8_t at all.  Actually no wonder
  because both predate C99.

  However, even the current Intel386 psABI 1.1 (2015) has nothing here,
  nor does the AMD64 psABI 1.0 (2024).

  To my astonishment however, the SPARC Compliance Definition 2.4.1
  (1999), defacto if not in name the SPARC V9 psABI, lists in Figure
  6-140: <inttypes.h>, p.6P-13:

  typedef signed char int8_t;

  So it seems at least Solaris/SPARCV9 violates its own ABI ;-(

* When checking clang, there were more surprises:

#define __INT8_TYPE__ signed char

  With very few exceptions, clang uses the default definitions of the
  intN_t types everywhere.

  However, the question remains how much that counts: given clang/llvm
  has seen years of neglect on Solaris, I wonder how much actual code is
  really built with it on Solaris.

* The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all
  AFAICT.  If that's true, one could change the type's definition simply
  by adjusting <sys/int_types.h>, which would be nice and easy.