https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713
Jens Gustedt changed:
What|Removed |Added
CC||jens.gustedt at inria dot fr
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 o
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 `_BitInt
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
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 built
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,
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&action=edit
simple pre-pro only file that crashes gcc-12
Hi,
the attached code, m
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&action=edit
complete example to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #21 from Jens Gustedt ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #20 from Jens Gustedt ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
--- Comment #2 from Jens Gustedt ---
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #16 from Jens Gustedt ---
(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 compli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #14 from Jens Gustedt ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #13 from Jens Gustedt ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #11 from Jens Gustedt ---
(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 standa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #8 from Jens Gustedt ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #7 from Jens Gustedt ---
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 #4 from Jens Gustedt ---
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 ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #2 from Jens Gustedt ---
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
: 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;
> ^
> type
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=35015&action=edit
code to reproduce compiler crash
The attached, very contrived code, has gcc crashing with
25 matches
Mail list logo
