[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 #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 #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 #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] 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/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/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=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 c/70891] New: "register name not specified" for const qualified register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70891
Bug ID: 70891
Summary: "register name not specified" for const qualified
register variable
Product: gcc
Version: 5.3.1
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 38387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38387=edit
complete example to reproduce the bug
Gcc in different variants (I tried 4.8, 4.9 and 5.3) gives an error for
register const struct large max4 = { .x0 = -1, .x1 = -1, };
Where large is just a struct consisting of two unsigned.
the error is
gcc-register-const-bug.c:27:31: error: register name not specified for
'max4'
which seems to refer to the "asm register" extension of gcc, but which isn't
used here at all.
The example is minimal in the sense that *any* of the following has the bug
disappear
- removing the const qualification
- removing the register storage class
- changing any of the initial values from -1 to 0
I attach a complete example that on my machine (x86_64) errors out exactly on
the line as indicated. All other variants in that file compile just fine.
As another data point, clang, in different versions, has no problem with this
code at all.
Thanks
Jens
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #20 from Jens Gustedt jens.gustedt at inria dot fr --- I would be much happier with a generic operator that makes any object into an rvalue. One way that comes close would be `1 ? (X) : (X)`. This is an expression that transforms any expression `X` that is not a narrow integer type into an rvalue. Unfortunately it is too ugly that anybody ever will systematically write `__typeof__(1?(X):(X))`. But a macro #define __typeof_unqual__(X) __typeof__(1?(X):(X)) could do. (And one could fix the finite number of cases that are not covered with `_Generic`.) I'd like to have prefix `+` for that. This could be useful in `__typeof__` but also in `_Generic`. Maybe gcc could extend that operator to be applicable to all types.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #21 from Jens Gustedt jens.gustedt at inria dot fr --- I would be much happier with a generic operator that makes any object into an rvalue. One way that comes close would be `1 ? (X) : (X)`. This is an expression that transforms any expression `X` that is not a narrow integer type into an rvalue. Unfortunately it is too ugly that anybody ever will systematically write `__typeof__(1?(X):(X))`. But a macro #define __typeof_unqual__(X) __typeof__(1?(X):(X)) could do. (And one could fix the finite number of cases that are not covered with `_Generic`.) I'd like to have prefix `+` for that. This could be useful in `__typeof__` but also in `_Generic`. Maybe gcc could extend that operator to be applicable to all types.
[Bug c/65471] type interpretation in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471 --- Comment #2 from Jens Gustedt jens.gustedt at inria dot fr --- For referece, I have now a paper at the ISO committee: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1930.htm we will look at it in the automn session to decide what to do with it.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #11 from Jens Gustedt jens.gustedt at inria dot fr --- (In reply to jos...@codesourcery.com from comment #10) On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote: (Perhaps gcc interprets _Generic as you say, but even the standard committee doesn't agree on that interpretation, and other compiler implementors don't agree either. Nothing in the standard says that it is an rvalue, nor that it has to undergo any conversion. Conversion for non-evaluated expressions simply doesn't exist in the standard. The standard explicitly asks for compatible type of the expression itself, it says nothing about unqualified type.) There isn't yet a conclusion to DR#423, but the committee discussion in N1892 says 'Specifically, the controlling expression of a generic selection was very carefully not added to the list of cases where lvalue conversion is not done.' (i.e. that conversion happens to all expressions unless excluded from happening). There is no indication of a committee direction contradicting the approach I chose for GCC (even if the committee isn't quite sure of how to handle atomics there, and has suggested making qualifiers on function return types not part of the type). And now we are exactly in the situation that I was afraid of happening, compiler implementors interpret _Generic differently. Your interpretation and the one that clang applies differ and make it that code with _Generic isn't portable. That is just a disaster for an early (well not so early anymore) adoption of C11.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #13 from Jens Gustedt jens.gustedt at inria dot fr --- (In reply to Marek Polacek from comment #12) What does clang differently wrt _Generic? Arrays. I don't recall which way around, but one of gcc and clang converts array types to pointers and the other not. Something like _Generic(bla, ...) has different outcome according to the compiler.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #14 from Jens Gustedt jens.gustedt at inria dot fr --- Perhaps we should end the discussion here, this goes too far for a bug report, and we should push for a solution of this type of questions by the C committee. Perhaps you could leave this bug open, even if you don't agree that it is a bug in gcc itself. It certainly is an issue that users of that feature in gcc should be aware of. I think that this should be resolved in one way or another, best by having a clear policy in the C standard itself what to do in such situations.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #16 from Jens Gustedt jens.gustedt at inria dot fr --- (In reply to Jakub Jelinek from comment #15) Usually such bugs are SUSPENDED with reference to the DR and when the DR is resolved, the bug is resolved accordingly. Here the situation is a bit more complicated, since __typeof__ is an extension to C, so no DR will directly say something about this. Do you want me to open a new bug for the observation that _Generic leads to compiler specific results?
[Bug c/65471] New: type interpretation in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
Bug ID: 65471
Summary: type interpretation in _Generic
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
This is a bug marker for an underspecification in the C11 standard, that has
been observed in DR#423
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_423
gcc and clang went quite opposite ways to resolve that issue, resulting in
severe incompatibility for _Generic expression that use qualifiers or arrays.
The following six lines illustrate the problem
char const* a = _Generic(bla, char*: blu); // clang error
char const* b = _Generic(bla, char[4]: blu); // gcc error
char const* c = _Generic((int const){ 0 }, int: blu);// clang error
char const* d = _Generic((int const){ 0 }, int const: blu); // gcc error
char const* e = _Generic(+(int const){ 0 }, int: blu); // both ok
char const* f = _Generic(+(int const){ 0 }, int const: blu); // both error
the last two lines, where gcc and clang agree, points to the nature of the
problem: gcc treats all such expressions as rvalues, clang as lvalues.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #4 from Jens Gustedt jens.gustedt at inria dot fr --- This is a surprising policy change that occurs a random point in time, namely where _Atomic is introduced to the C language and in addition does that in a very unituitive way. Why drop _Atomic, why keep the others. Also it doesn't look very consistent to me: on one hand you claim that it is necessary for the implementation of stdatomic.h, but that now uses __auto_type. For __auto_type the drop of qualifiers comes quite naturally since the RHS is evaluated anyhow. So basically the drop of _Atomic qualifiers by __typeof__ is a historic artefact that maybe has been needed in a short period of time for one internal use case in libatomic. Please consider changing this to a more comprehensive behavior.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #8 from Jens Gustedt jens.gustedt at inria dot fr --- (Perhaps gcc interprets _Generic as you say, but even the standard committee doesn't agree on that interpretation, and other compiler implementors don't agree either. Nothing in the standard says that it is an rvalue, nor that it has to undergo any conversion. Conversion for non-evaluated expressions simply doesn't exist in the standard. The standard explicitly asks for compatible type of the expression itself, it says nothing about unqualified type.)
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #7 from Jens Gustedt jens.gustedt at inria dot fr --- This bugzilla really sucks. There is my second comment that I place here gone to the void. Obviously you did see it, since you replied to my mention of _Generic, but now its gone.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #2 from Jens Gustedt jens.gustedt at inria dot fr --- Since typeof is a gcc extension, there is not much arguing about it, but this sounds wrong to me. Use cases I have, and that I seen used by others are for example something like _Atomic int a; __typeof__(a) b __attribute__((weak,alias(a))); This would systematically fail with that approach. When _Atomic will go into wider use these difficulties will pop up more often. Eliminating qualifiers in expressions is easy for arithmetic types at least, something like __typeof__((a)+0) b; should always do the trick. In P99 I have implemented an equivalent to stdatomic.h that seems to work well without assuming a drop of qualifiers. (and BTW, the current version of stdatomic.h uses __auto_type, which makes it incompatible with clang.)
[Bug c/65455] New: typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 Bug ID: 65455 Summary: typeof _Atomic fails Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.gustedt at inria dot fr The following declarations _Atomic int a; __typeof__(a) a; result in compile errors: typeof_atomic.c:2:15: error: conflicting type qualifiers for 'a' __typeof__(a) a; ^ typeof_atomic.c:1:13: note: previous declaration of 'a' was here _Atomic int a; This could be related to bug #65345. Jens
[Bug c/65395] New: compiler crash, -ftree-pre leads to SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65395 Bug ID: 65395 Summary: compiler crash, -ftree-pre leads to SSA corruption Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.gustedt at inria dot fr Created attachment 35015 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35015action=edit code to reproduce compiler crash The attached, very contrived code, has gcc crashing with gcc -c -O3 orwl_proc_symbols-prepro.c the code compiles fine with gcc -c -O3 -fno-tree-pre orwl_proc_symbols-prepro.c As indicated the code is very contrived and the result of reducing a complicated macro expanded code to a minimal example. So the one I give here seems to be minimal to reproduce the crash. It has - nested for loops of a depth 15 or so - uses setjmp (but no longjmp) - uses an inline function that does not much but calling a _Noreturn function conditionally without any of these components the bug goes away ... BTW, I observed the bug already for earlier versions of gcc 4.9. gcc 4.8 works fine. My system is a x86_64 with debian jessie, nothing fancy.
