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
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
> >
>
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
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
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
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
>
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
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
: 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 prov
ty: 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
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
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
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.
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
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
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
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
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
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
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
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.
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
: 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
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
24 matches
Mail list logo
