[Bug c/113886] New: new C23 length specifier with confusing diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113886
Bug ID: 113886
Summary: new C23 length specifier with confusing diagnostic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.gustedt at inria dot fr
Target Milestone: ---
I am currently implementing the new %wN length specifiers for C23 in musl, and
the compiler support in gcc already works well for those N that actually exist,
it seems. Unfortunately the diagnostic for those where it doesn't are confusing
```
#include
#include
int main() {
uint32_t x = 2;
printf("%w31x\n", x); // works for 32 instead of 31
}
```
Here gcc (as of trunk on godbolt with '-std=c2x -Wall') tells me
:6:14: warning: unknown conversion type character 'w' in format
[-Wformat=]
6 | printf("%w31x\n", x);
which is quite confusing because it is not the 'w' which wrong, but the number
following it.
[Bug c/113887] New: no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
Bug ID: 113887
Summary: no support for %w128 length modifiers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.gustedt at inria dot fr
Target Milestone: ---
With C23 and the %w length modifiers and `_BitInt(128)` literals, it will
finally be possible to have `[u]int128_t` types consistently as type aliases
for all architectures where gcc defines the `__int128` types. I am currently
implementing such a support on musl, but unfortunately the %w128 length
modifiers are diagnosed as being wrong.
```
#include
int main() {
unsigned __int128 x = 2;
printf("%w128x\n", x);
}
```
[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 #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 #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 #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 #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 #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/109284] New: __VA_OPT__ triggers internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109284 Bug ID: 109284 Summary: __VA_OPT__ triggers internal compiler error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.gustedt at inria dot fr Target Milestone: --- Created attachment 54755 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54755&action=edit simple pre-pro only file that crashes gcc-12 Hi, the attached code, meant to provide a feature test for `__VA_OPT__`, crashes my compiler: gcc-12-va-opt-bug.c:15:1: internal compiler error: unspellable token PADDING I am on an standard Ubuntu, nothing fancy: gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04) Jens
[Bug analyzer/101713] -Wanalyzer-malloc-leak false positive with GNU coreutils hash table code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713 Jens Gustedt changed: What|Removed |Added CC||jens.gustedt at inria dot fr --- Comment #4 from Jens Gustedt --- Still a problem here with gcc-13. Makes -Wanalyzer-malloc-leak basically useless for me.
