https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #9 from Jakub Jelinek ---
Apparently we are missing range implementation of casts between different
floating point types as well.
Trying now:
--- gcc/range-op-mixed.h.jj 2025-05-20 08:14:06.520404648 +0200
+++ gcc/range-op-mixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61549|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
--- Comment #4 from Jakub Jelinek ---
You mean before 15.2? I guess I could.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120480
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61546|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120473
--- Comment #1 from Jakub Jelinek ---
Seems __cxa_begin_catch for all the pointers returns them by value rather than
pointer to the pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120473
Bug ID: 120473
Summary: Pointers caught with pointer &var handler not
modificable
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61540|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120464
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120464
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |16.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120464
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61528|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #16 from Jakub Jelinek ---
So, the paper added also the new case to
https://eel.is/c++draft/expr.const#10.27
but
https://eel.is/c++draft/expr.new#8.5
has not been changed and still says that say new int[-1] in constexpr function
is i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120449
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61526|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #13 from Jakub Jelinek ---
(In reply to Hana Dusíková from comment #12)
> I'm using [[gnu::used]] to emit constexpr symbol so it can be part of
> compatible interface.
I think we don't have a problem with exporting the ABI compatibl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #10 from Jakub Jelinek ---
Ok, so do we want some attribute for
std::{exception,bad_exception,bad_alloc,bad_cast,
bad_typeid,bad_weak_ptr,bad_function_call} and perhaps others which will
pretend they have a key function even if they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #8 from Jakub Jelinek ---
Note, adding _GLIBCXX26_CONSTEXPR above for the defaulted or inline defined
methods is ok and they wouldn't need to be treated like magic builtins (though
I guess
exception_ptr copy ctor and dtor need specia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #7 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #6)
> (In reply to Jakub Jelinek from comment #3)
> > Jonathan, thoughts on the library side?
> > E.g. std::uncaught_exceptions is just declared in the header, but if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61521|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434
--- Comment #8 from Jakub Jelinek ---
If we wanted to do it in some GIMPLE pass (e.g. VRP or whatever other suitable
late GIMPLE pass which uses the ranger), we'd need a target hook to choose
preference of sign or zero extension and then probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120438
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 Regression] explicit |[12 Regression] explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 regression] |[12 regression] Miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] wrong |[12 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117358
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] ICE: |[12 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
--- Comment #19 from Jakub Jelinek ---
Fixed for 13.4 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116636
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 Regression] |[12 Regression] Deprecation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 Regression] strlen |[12 Regression] strlen of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61493|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99015
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98991
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13 Regression] -Os |[12 Regression] -Os breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418
--- Comment #5 from Jakub Jelinek ---
I use the same dejagnu and they don't fail. And looking at e.g. the
gcc-testresults mailing lists, they don't fail for others either (there are
some pch/embed-1.c failures in freebsd results but that looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418
--- Comment #2 from Jakub Jelinek ---
Why do you do that?
The tests are meant to be tested with dejagnu, using make check.
That passes absolute filenames, which works just fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120196
--- Comment #8 from Jakub Jelinek ---
Fixed also for 13.4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191
--- Comment #21 from Jakub Jelinek ---
Fixed also for 13.4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #7 from Jakub Jelinek ---
I think this is on
using GroupedItems = hash_map, XXHasher>;
static void printItemMap(const GroupedItems& itemMap)
{
auto printSet = to_vector(view::transform(itemMap, [](auto& p) {
return strCat(formatSe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Jakub Jelinek changed:
What|Removed |Added
Summary|[14/15/16 Regression] |[14/15/16 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #2 from Jakub Jelinek ---
Created attachment 61493
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61493&action=edit
gcc16-pr117785-wip.patch
Very early WIP patch.
This can right now handle a trivial exception throwing + catchi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #8 from Jakub Jelinek ---
In any case, #c5 and onwards is completely unrelated to this PR, which is about
value ranges for casts from integers to floating point and vice versa. So,
please move that elsewhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #7 from Jakub Jelinek ---
(In reply to Alex Coplan from comment #6)
> I suppose that example boils down to whether code like:
>
> _Bool f(_Float16 a) {
> return a * a >= 0;
> }
> _Bool g(float a) {
> return a * a >= 0;
> }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120360
--- Comment #6 from Jakub Jelinek ---
That is hack to avoid emitting constants that match the endbr64 or endbr32
instructions in the immediates. Normally that is done when checking the
immediates, but here they are negated and I didn't want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120360
--- Comment #4 from Jakub Jelinek ---
Created attachment 61480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61480&action=edit
gcc16-pr120360.patch
Untested fix for #c2/#c3. We already had *cmp_minus_1 pattern which
handles the case whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119695
--- Comment #3 from Jakub Jelinek ---
(In reply to James K. Lowden from comment #2)
> > The ones mentioning 'z' are gettext fault, %zd/%zu is supported in
> > gcc-internal-format.
>
> gettext "15.3.1 C Format Strings" references POSIX,
>
> h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120310
--- Comment #2 from Jakub Jelinek ---
Guess one case is when tree DSE removes all stores to some automatic
addressable variable, in that case it would be nice to populate debug stmts to
all those removed locs and state what values it had there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120310
Bug ID: 120310
Summary: Missing location for initially addressable variable
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #4 from Jakub Jelinek ---
But of course then it needs to be mangled differently from long double and
_Float128 too.
Itanium ABI documents e for long double, g for __float128 and DF128_ for
_Float128,
not really sure if g isn't alread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #3 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Rainer Orth from comment #0)
> > * I initially tried aliasing __float128 to _Float128, but that broke the
> > libstdc++ build:
>
> Libstdc++ co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
--- Comment #7 from Jakub Jelinek ---
I guess it depends on what approach is used to fix this.
If just handling error_mark_node gracefully during the mangling (emit something
in that case, what exactly doesn't matter much) and/or somehow figure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
--- Comment #5 from Jakub Jelinek ---
And with s/auto/constexpr auto/g after even more errors ICEs starting with
r5-2539-g4a4f287dc1ae6f111b28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
--- Comment #3 from Jakub Jelinek ---
With -std=c++0x #c1 ICEs starting with r5-2991-g5e0231c231404677aa1b9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278
--- Comment #11 from Jakub Jelinek ---
Dead branches and dead code definitely appear in -O0 code just about
everywhere, that is not about correctness but about efficiency, which is a
non-goal for -O0.
Even at higher optimization levels compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278
--- Comment #9 from Jakub Jelinek ---
If you are using -O0 for production code where performance matters, you're
doing something wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] g++ |[12/13 Regression] g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120284
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120254
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #5 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120254
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120247
--- Comment #6 from Jakub Jelinek ---
Perhaps __builtin_assoc_barrier should lower to NON_LVALUE_EXPR (PAREN_EXPR
(expr))
or PAREN_EXPR (NON_LVALUE_EXPR (expr)) for C++?
Of course, a big question is what the builtin should do for class types (if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120247
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120196
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120250
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15/16 Regression] |[12/13/14/15/16 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86769
--- Comment #26 from Jakub Jelinek ---
Note, this had the PR118822 r15-7502 follow-up, so not really sure it is a good
idea to backport this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #3 from Jakub Jelinek ---
Yeah, I'd definitely appreciate blank handlers for those, which I can gradually
try to implement. Working now on big-endian _BitInt, so it won't be
immediately, but will try to get to it before summer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120238
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120205
--- Comment #3 from Jakub Jelinek ---
The reduction is wrong in many ways.
main shouldn't have a single char argument, fgets inline doesn't return
anything if __bdos is not -1, otherwise it calls fgets without any arguments,
all that is UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191
--- Comment #7 from Jakub Jelinek ---
Created attachment 61384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61384&action=edit
gcc16-pr120191.patch
This seems to work even when the kind argument is not named, just doing for
minmaxloc wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191
--- Comment #4 from Jakub Jelinek ---
Yes. You need to write a ChangeLog entry, which would be in this case I think
something like
PR fortran/120191
* trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc):
Call strip_kind_fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191
--- Comment #6 from Jakub Jelinek ---
Note, the test even with your patch FAILs for -O0 and -Os, first on STOP 17, I
see quite a few invocations still with 6 arguments:
grep maxloc.*,.*,.*,.*,.*,.* pr120191.f90.007t.gimple
[pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2025-05-09
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
Bug ID: 120193
Summary: Incorrect debug info for unsigned(kind=1) and
unsigned(kind=4)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191
--- Comment #2 from Jakub Jelinek ---
Created attachment 61380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61380&action=edit
gcc16-pr120191-test.patch
Perhaps like this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
--- Comment #14 from Jakub Jelinek ---
So fixed for 14.3+/15.2+/16+ ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125
--- Comment #5 from Jakub Jelinek ---
The WIP patch looks reasonable to me.
On which testcase you see something weird? On the #c1 I don't see anything
wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] -Os |[12/13 Regression] -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158
Bug ID: 120158
Summary: Incorrect UNSIGNED maxval/maxloc etc.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153
--- Comment #1 from Jakub Jelinek ---
Created attachment 61351
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61351&action=edit
gcc16-pr120153.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153
Bug ID: 120153
Summary: Missing UINTEGER symbols
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152
--- Comment #1 from Jakub Jelinek ---
Created attachment 61350
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61350&action=edit
gcc16-pr120152.patch
So far lightly tested patch. The abilist regressions are gone with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
1 - 100 of 5862 matches
Mail list logo
