|1
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2025-06-03
--- Comment #1 from Jakub Jelinek ---
For strncat/wcsncat we don't need to do anything, the builtins are already
handled correctl
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: bruno at clisp dot org, daniel.kruegler at googlemail dot
com,
egallager at gcc dot gnu.org, jakub at gcc dot gnu.org
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.
rmal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
const char r[] = "hello";
const char *s[] = { &r[0], &r[3] };
const char **p = &s[0];
int
foo ()
{
try
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Attachment #61540|0 |1
is obsolete|
|RESOLVED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
Should be fixed now.
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
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
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
,
||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Like for divmod, expansion can use get_range_pos_neg (treeop) == 1 test to find
out if the value range for some tree is known to be in the range [0,
signed_max] and then could try to expand the
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
||
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #4 from Jakub Jelinek ---
Created attachment 61521
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61521&action=edi
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
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.
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Consider -O2 -g -dA
volatile int v;
void foo () { int a = 42; int *b = &a; ++v; }
struct S { int *p; int q; };
void bar () { int a = 42; ++a; struct S b = { &am
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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
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
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #17 from Jakub Jelinek ---
Fixed for 14.3/15.2/16+ for now.
||r12-4475
CC||jakub at gcc dot gnu.org,
||sayle at gcc dot gnu.org
Priority|P3 |P2
--- Comment #2 from Jakub Jelinek ---
Started with r12-4475
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.
)
||since r12-657
CC||jakub at gcc dot gnu.org
Keywords|needs-bisection |
--- Comment #1 from Jakub Jelinek ---
Started with r12-657-ga076632e274abe344ca7648b7c7f299273d4cbe0
||amacleod at redhat dot com,
||jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-05-12
--- Comment #1 from Jakub Jelinek ---
I think we don't have value
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
|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Created attachment 61383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61383&acti
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
unsigned(kind=1) :: a(2), e
unsigned(kind=2) :: b(2), f
unsigned(kind=4) :: c(2), g
unsigned(kind=8) :: d(2), h
a = 1u_1
b
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
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
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #24 from Jakub Jelinek ---
Should be hopefully fixed now for 14.3, 15.2 and 16+.
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
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
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
maxval/maxloc use
#if defined('atype_inf`)
maxval = -atype_inf;
#else
maxval = atype_min;
#endif',
compared to minval/minloc
#if defined('atype_i
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.
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Looking at the GFORTRAN_15 symbols, I miss 4 symbols.
In particular
_gfortran_arandom_m16
_gfortran_maxloc1_16_m16
_gfortran_mmaxloc1_16_m16
_gfortran_smaxloc1_16_m16
The first one is caused
1 - 100 of 14818 matches
Mail list logo
