https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #3 from Jens Gustedt <jens.gustedt at inria dot fr> ---
(In reply to Jakub Jelinek from comment #1)
> AFAIK glibc doesn't support %w128d etc., it would require full
> int128_t/uint128_t support, likely
> int_least128_t/uint_least128_t/int_fast128_t/uint_fast128_t,
> INT128_WIDTH/UINT128_WIDTH, {,U}INT_{LEAST,FAST}128_WIDTH, INT128_C,
> UINT128_C, ...
>
> I'm not sure one can use wb/uwb literal suffixes because at least in GCC
> _BitInt support is for now x86_64 only (with posted patches for
> ia32/aarch64) and in clang the support is without stable ABI, so perhaps if
> enabled, it would need to be limited to
> __BITINT_MAXWIDTH__ >= 128 targets, because without some __int128 specific
> suffixes or
> __BITINT_MAXWIDTH__ >= 128 one can't support INT128_C or UINT128_C.
yes, sure, but checking that all planets align to provide int128_t is the task
of the headers, which should be provided by the C library, not the compiler.
the compiler provides the feature test macros (for the __int128 types and
_BitInt at least for 128 bit) and with that information the library is able to
provide the remaining information in stdint.h and inttypes.h
The question for the %W flag is just not to confuse the user with wrong
information.
to be clear, all of this works with my current patches for musl without
problem, only the diag given by the compiler is wrong.
