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

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14)
> 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 ;-(

Ouch!

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

That's interesting. I think GCC defines those __INTn_TYPE__ macros after
inspecting the target headers (assuming the target provides <stdint.h> or
<inttypes.h>) to ensure they agree. I wonder if Clang intentionally deviated
from the Solaris headers to "fix" this issue, or if they just define
__INT8_TYPE__ to signed char for all 8-bit targets because "obviously" that's
correct for all targets (even though it isn't actually correct for Solaris).

That means GCC and Clang will disagree about the mangling of a C++ function
like
void foo(int8_t);

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

I think those macros are a GCC thing not required by any standard. Oracle
Studio can just rely on <stdint.h> being present, because they know that's true
for Solaris. GCC can't (or couldn't historically) rely on <stdint.h> being
present for all targets so needed some other way to make those types available.

Thanks for digging into this!