[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #12 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #11) > As I said in comment#2, I prefer a constant suffix for __int128 to the > wb/uwb hack - I think it's cleaner, as well as allowing int128_t to work > properly on all the targets that support __int128 but have not so far had an > ABI for _BitInt defined, or not had such an ABI implemented in GCC. Maybe. But that does not have much to do with the very specific question asked here.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #11 from Joseph S. Myers --- As I said in comment#2, I prefer a constant suffix for __int128 to the wb/uwb hack - I think it's cleaner, as well as allowing int128_t to work properly on all the targets that support __int128 but have not so far had an ABI for _BitInt defined, or not had such an ABI implemented in GCC. (I also think it's time to chase up target maintainers for all the architectures that don't yet have _BitInt support, which is almost all of them, inviting them to sort out an ABI definition either locally in GCC, in conjunction with other implementations or in an actual ABI document, as appropriate depending on the extent to which GCC for that target tries to interoperate with other implementations or externally defined ABIs, and then add the support, but that's a separate matter.)
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #10 from Jakub Jelinek --- #if 42 == ((__int128) +42wb) && -35 == ((__int128) +-35wb) #else #warning warn #endif works with both gcc and clang if __BITINT_MAXWIDTH__ >= 128. That said, for UINT128_C it would need to use __uint128_t rather than unsigned __int128, as the latter doesn't work in preprocessor expressions, as that is interpreted as ((0 0) +42wb) then.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #9 from Jens Gustedt --- (In reply to Jakub Jelinek from comment #8) > > #define INT128_C(N) ((__int128)+ N ## W) > > You mean WB? Yes, probably ;-) > > With that observation you easily also create `MIN` and `MAX` macros > > > > #define INT128_MAX (INT128_C(1) << 126) > > That is certainly not the right INT128_MAX. Yes, again, sorry. I should not post these things when I am too tired. But I hope you get the idea that some form of constant expression with some bit operations will do the trick.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #8 from Jakub Jelinek --- (In reply to Jens Gustedt from comment #7) > (In reply to Joseph S. Myers from comment #5) > > ... including __INT128_C and __UINT128_C > > defined to use an appropriate constant suffix. > > You don't need a specific suffix for these types if you have `_BitInt(128)`, > there is no need to invest thoughts or development time in this. > Something like > > #define INT128_C(N) ((__int128)+ N ## W) You mean WB? > With that observation you easily also create `MIN` and `MAX` macros > > #define INT128_MAX (INT128_C(1) << 126) That is certainly not the right INT128_MAX. The right value is INT128_C (170141183460469231731687303715884105727) while INT128_C(1) << 126 is just INT128_C (85070591730234615865843651857942052864).
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #7 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #5) > ... including __INT128_C and __UINT128_C > defined to use an appropriate constant suffix. You don't need a specific suffix for these types if you have `_BitInt(128)`, there is no need to invest thoughts or development time in this. Something like #define INT128_C(N) ((__int128)+ N ## W) would do. If 128 is more than `INTMAX_WIDTH` the resulting constants are exempted by C23 of being suitable for preprocessor arithmetic. But if it is indeed 128, the expression still is an integer constant expression, even in the preprocessor. With that observation you easily also create `MIN` and `MAX` macros #define INT128_MAX (INT128_C(1) << 126) #define INT128_MIN (-INT128_MAX - 1)
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #6 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #5) > Compiler and library are not in practice independent for this issue ... For this particular issue they are indeed independent. As said, I have proof of concept that it works with patches for musl, only gcc is whining because it doesn't understand the `w128` flag. Otherwise, it is fully functional. Again, I am not asking that gcc implements full support for the `int128_t` type alias. I am only asking that `w128` is recognized if and only if the compiler has `__int128` and if so, does the right diagnosis for the argument type. And this has nothing to do with free standing, only with hosted environments. This is not enabling `int128_t` but enabling C libraries to provide `int128_t` on top of `__int128` if they are able to fill in the gaps. And indeed, once there is `_BitInt(128)` in the compiler and then the library provides the `w128` an `wf128` flags, everything is indeed easily filled. For freestanding which doesn't need things are even simpler, they only need `_BitInt(128)` to provide the `.._C` macros if they know that they have `__int128`.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #5 from Joseph S. Myers --- Compiler and library are not in practice independent for this issue. GCC typically provides for freestanding compilations and forwards to a libc version for hosted compilations, and in both cases it needs to know what the types are for correct format checking (for example, whether int64_t is long or long long) - and it needs to know that even in files that didn't include , and preferably the types should be the same for hosted and freestanding. In fact it needs to know the types even when not compiling C or C++ - Fortran ISO_C_BINDING supports those types (though the Fortran standard has a specific list, not mentioning int128_t or general intN_t). And to properly support implementation - whether in GCC's or one provided by libc - any int128_t support should come with all the associated predefined macros - including __INT128_C and __UINT128_C defined to use an appropriate constant suffix.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #4 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #2) This is not about the question if the C library supports these types as `uint128_t`. This is primarily to provide `printf` etc *interface* support for the builtin type by means of the new C23 specifiers. C compiler and C library should be independent on this as much as possible, because all combinations of old/new compile/library should work without problems. The musl implementation of the length specifiers does for example not rely any compiler support for the types. It only uses a convention on how to pass 128 bit types as `va_arg` and which of the two 64 halves is high and which is low. For the format checker in the compiler this just asks: - accept w128 and wf128 specifiers iff the platform supports 128 bit integer types - check if the corresponding argument has such a type
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #3 from Jens Gustedt ---
(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.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #2 from Joseph S. Myers --- https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643237.html has my notes on things that need supporting, in , and by implication in printf and scanf, to support __int128 as an extended integer type for C23 and thus support int128_t, uint128_t, int_least128_t and uint_least128_t in . I think we *should* add such support in GCC (thus, including GCC's for the freestanding case - header changes appropriately conditional on C23 mode) and glibc. Not of course in GCC 14 at the current development stage, as it's clearly a new feature. I think it should be done with an integer constant suffix (say i128 / I128 - potentially confusing if used together with 'i' for complex integers, but not ambiguous), rather than using wb/uwb together with the hack of making macros expand to e.g. ((__int128) +123wb) to get the right type (the '+' together with the cast, to a type name that's interpreted as 0 in the preprocessor, allows such an expression to work in #if expressions as long as the value is within the range of intmax_t which is all that's allowed there). When adding such a feature to glibc we'd need to consider what user-visible features are appropriate beyond the header changes and printf/scanf support. That probably includes functions such as strotoi128 / wcstoi128 and the unsigned and _l versions thereof (using C23 semantics unconditionally for 0b, I suppose), maybe also i128abs, i128div. The type-generic macros in stdbit.h mean we don't need extra type-specific functions there. The default printf/scanf format checking in GCC is effectively for things that are either standard or in glibc - and w128 is only standard when you have support for int128_t and all the pieces that go along with that, at least on the compiler side. (I'm supposing you don't want separate musl_printf format checking support - although such a thing is possible, we do have separate ms_printf support for Windows target.)
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jsm28 at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
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.
