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

Unfortunately not: gcc hardcodes all those types all over gcc/config
(e.g. sol2.h) as INT8_TYPE.

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

I guess no one cared enough about Solaris in Clang to notice this.
There isn't even a test to check if Clang's internal idea of e.g. int8_t
and that of the system headers match (but neither does gcc).

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

As I found, they won't: while their internal definitions of
__INT8_TYPE__ differ, when one wants to use int8_t, one needs to include
a corresponding header (<stdint.h>/<inttypes.h>/<cstdint>), thus will
always get what the header defines.

Only when using __INT8_TYPE__ directly will you get the mangled form of
the compiler's internal idea of int8_t.

To check what happens, I've re-run last night bootstraps (sparc and x86)
with <sys/int_types.h> changed to define int8_t and friends as signed
char, at the same time modifying gcc/config/sol2.h to match.

The bootstrap (i386 so far, sparc still running, though I don't expect
any difference) went without issues: the only regression seen is

+UNRESOLVED: gdc.test/runnable_cxx/stdint.d   compilation failed to produce
executable
+UNRESOLVED: gdc.test/runnable_cxx/stdint.d -shared-libphobos   compilation
failed to produce executable

where the executable fails to link:

Undefined                       first referenced
 symbol                             in file
_Z15testCppI8Manglechchch           /var/tmp//ccJLlOBa.o

This test has D (stdint.d) and C++ (extra-files/stdint.cpp) components,
checking the gdc and g++'s ideas of various types match.  Unlike C/C++,
where the definition of int8_t is from <sys/int_types.h>, D has it's
equivalent in libphobos/libdruntime/core/stdc/stdint.d which will have
to be adjusted, too.

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

I guess so: I just meant to find out if cc/CC has it's own idea of the
types apart from the system headers.  However, going forward, this can
certainly learned from Oracle.

I'll think given the information so far, I'll take the idea of changing
int8_t for C99+ conformance to them and see what they think.