https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120993
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121005
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-07-09
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121005
--- Comment #2 from Richard Biener ---
Best have a TREE_BASE_BITS accessor that captures this, it applies to quite
some other accessors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121006
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-07-09
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121011
--- Comment #2 from Richard Biener ---
There's a duplicate about this (assigned to me even, IIRC). final value
replacement is currently done opportunistically rather than as utility to
passes where it would be useful (DCE of the loop, avoiding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121006
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> Confirmed, but does this happen in practice?
The zero case might happen the most. Otherwise I doubt very much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843
--- Comment #12 from GCC Commits ---
The releases/gcc-15 branch has been updated by Andre Vehreschild
:
https://gcc.gnu.org/g:120efb3931260de35173267ec6870d8f17fbadb5
commit r15-9945-g120efb3931260de35173267ec6870d8f17fbadb5
Author: Andre Vehr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843
Andre Vehreschild changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #7 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:6c8d221b74869f2760ded2d67f95dd9d275bc1a2
commit r16-2119-g6c8d221b74869f2760ded2d67f95dd9d275bc1a2
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #8 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:963d5362c598d48ee7a896e674d2a68c41179785
commit r16-2120-g963d5362c598d48ee7a896e674d2a68c41179785
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #9 from Tamar Christina ---
(In reply to Robin Dapp from comment #6)
> (In reply to Tamar Christina from comment #5)
> > Question, can I count on
> >
> > -march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8
> >
> > alway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
--- Comment #5 from GCC Commits ---
The master branch has been updated by Victor Do Nascimento
:
https://gcc.gnu.org/g:f33cc3af8fd9c498bd02623168054d76a0989ed6
commit r16-2134-gf33cc3af8fd9c498bd02623168054d76a0989ed6
Author: Icen Zeyada
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:2e6dc9e19cdac43354608a1fc29fe31ec614775c
commit r16-2135-g2e6dc9e19cdac43354608a1fc29fe31ec614775c
Author: Jan Dubiec
Date: Wed Jul 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196
--- Comment #4 from GCC Commits ---
The master branch has been updated by Victor Do Nascimento
:
https://gcc.gnu.org/g:f6eb8291e1c538f946efcb79b1f597c251be63c4
commit r16-2133-gf6eb8291e1c538f946efcb79b1f597c251be63c4
Author: Icen Zeyada
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
Oliver Old changed:
What|Removed |Added
CC||Oliver.Old at loewen dot de
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #463 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #462)
> (In reply to Oleg Endo from comment #461)
> > Yes, of course. I'm a little overloaded atm. I'll try to find some
> > peaceful moments to update/reba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120642
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
Sam James changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Target Milesto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
--- Comment #2 from Sam James ---
This fails with just -O2:
```
union {
int i;
float f;
} int_as_float_u;
int render_result_from_bake_w, render_result_from_bake_h_seed_pass;
float *render_result_from_bake_h_primitive, *render_result_from_ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121013
Bug ID: 121013
Summary: Possible miscompilation triggered by
__builtin_stack_address() at `-O3`.
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014
Bug ID: 121014
Summary: vectorizer uses RDIV_EXPR for integer types
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-07-09
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120093
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120093
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8f1cc1ceabdac21940fa0638298d8a3b7c941d4a
commit r16-2128-g8f1cc1ceabdac21940fa0638298d8a3b7c941d4a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120093
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
Bug 110339 depends on bug 117403, which changed state.
Bug 117403 Summary: [C++26] Implement P1901R2 Enabling the Use of weak_ptr as
Keys in Unordered Associative Containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:10b8379252e91c2e129f88482240b12ca392d5e2
commit r16-2131-g10b8379252e91c2e129f88482240b12ca392d5e2
Author: Paul Keir
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120642
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:f2e3886a30c771b104bc2714992e072b21a52e76
commit r16-2132-gf2e3886a30c771b104bc2714992e072b21a52e76
Author: Jeff Law
Date: Wed Jul 9 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> > we can cleanly see that _26 is an uninitialized variable, whose
> > initialization has been eliminated by the previous optimization already due
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #12 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #11)
> Is there anything that needs to be addressed for this one?
Yes, can this be backported to the 14 and 15 branches or are the changes too
intrusive? I j
ld-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250709 (experimental)
a09b415b87cd98e3a4f3e197ad4e9e67a335c1d4 (Gentoo Hardened 16.0. p, commit
9dd46ee2eb01d30892f1c6db1599e82a9c6e8b04)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
--- Comment #1 from Sam James ---
I'm reducing it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #462 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #461)
> Yes, of course. I'm a little overloaded atm. I'll try to find some
> peaceful moments to update/rebase the branch and commit the existing test
> cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120229
--- Comment #2 from Jan Hubicka ---
See thread
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689018.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96027
Oliver Old changed:
What|Removed |Added
CC||Oliver.Old at loewen dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
--- Comment #10 from Sam James ---
Created attachment 61824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61824&action=edit
ceval.i.xz
ceval.o is broken.
```
$ gcc -c -fno-strict-overflow -O2 -mavx -mtune=znver2 -std=c11
-fvisibility=hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #9 from Segher Boessenkool ---
Hrm, the insn here is just a mulldi instruction, a bog-standard integer
multiplication (by a constant, 6 here).
But insn 58 (where the problems start, "Changing address in insn 58
r218:DI&0xfff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121018
Bug ID: 121018
Summary: RVV codegen: spills unused vector registers on
function call between RVV intrinsics
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Why do you need CLASS_OF_SIZE argument? If count is in bytes, simply pass 1
> to the TYPE_SIZE_UNIT argument.
> ACCESS_MODE can be in the same argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #10)
> The problem is not restricted to mpi_isend.
This was supposed to read: ... not restricted to mpi_irecv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #11 from Jakub Jelinek ---
Though even there is uninitialized read I guess from temp.a.
That said, LRA obviously shouldn't hang even on code which has UB at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #10 from Jakub Jelinek ---
Slightly tweaked testcase to avoid -Wuninitialized as well as avoid the
aliasing violation.
typedef struct { int a; } A;
unsigned char *a;
char b;
int c;
void foo (vector char, vector char, vector char);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #10 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
> The problem if it is the scalar type rather than pointer to it is that it
> could be e.g. too narrow to fit all the ACCESS_MODE values there. Think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121013
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Return-Address.html#index-_005f_005fbuiltin_005fstack_005faddress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120999
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104547
--- Comment #13 from Jonathan Wakely ---
This test fails with this proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689128.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #9 from kargls at comcast dot net ---
(In reply to anlauf from comment #8)
> (In reply to Martin Jambor from comment #7)
> > (In reply to kargls from comment #5)
> > >
> > > So, if I understand, you want an fnspec of ". . w w w w w w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #6 from Jakub Jelinek ---
Reduced -mcpu=power9 -O2:
typedef struct { int a; } A;
unsigned char *a;
char b;
int c;
void foo (vector char, vector char, vector char);
void
bar (long stride)
{
vector char v0, v1, v2, v3, v4, v5;
ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #4 from qinzhao at gcc dot gnu.org ---
The size of the element of the FAM actually _cannot_ reliably depends on the
original TYPE of the FAM that we passed as the 6th parameter to the
.ACCESS_WITH_SIZE:
TYPE_SIZE_UNIT (TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #7 from qinzhao at gcc dot gnu.org ---
I need to modify the testing case as following to enable
__builtin_dynamic_object_size working as expected:
/* The parameter m must be const qualified to avoid the m is
marked as TREE_SIDE_E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #8 from Jakub Jelinek ---
The usual way would be to make the argument pointer to the scalar type,
basically have the access mode the same type as the second argument. So e.g.
int * or unsigned * or size_t * etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120794
--- Comment #3 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a
commit r16-2155-g069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a
Author: Robert Dubner
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119337
--- Comment #7 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a
commit r16-2155-g069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a
Author: Robert Dubner
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120765
--- Comment #2 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a
commit r16-2155-g069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a
Author: Robert Dubner
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #9 from Jakub Jelinek ---
The problem if it is the scalar type rather than pointer to it is that it could
be e.g. too narrow to fit all the ACCESS_MODE values there. Think about
unsigned _BitInt(1) counted_by.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120993
--- Comment #5 from Paul Eggert ---
(In reply to Bruno Haible from comment #4)
> in order to get a practically useful model, one should choose the
> maximum possible value of p.
>
> In the case of the 'double-double' representation, this value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #3 from Segher Boessenkool ---
Does anyone want to take this? Fame and fortune await!
We need a reduced test case btw :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #4 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #1)
> This is definitely sounding more and more like PR 93658.
Yes, and maybe the error / fix / workaround will be similar: replace a
VECTOR_MEM_ALTIVEC_P by VEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #5 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #4)
> So LRA gets into an infinite loop here as well, do we know that to be
> true already, is that actually seen?
Yes from the .reload dump:
```
Changing addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #12 from R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a72d0e1a8bf0770ddf1d8d0ebe589f92a4fab4ef
commit r16-2152-ga72d0e1a8bf0770ddf1d8d0ebe589f92a4fab4ef
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
--- Comment #13 from Sam James ---
It looks like the last commit this machine built python3.14t at was
r16-1594-gb03e0d69b37f6e which predates preserve_none being added
(r16-1692-g9804b23198b39f).
We had a similar problem in PR120840.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
--- Comment #14 from Sam James ---
(In reply to Sam James from comment #13)
> It looks like the last commit this machine built python3.14t at was
> r16-1594-gb03e0d69b37f6e which predates preserve_none being added
> (r16-1692-g9804b23198b39f).
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #1 from Marc Singer ---
Created attachment 61825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61825&action=edit
Preprocessed version of the failing source file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #7 from Segher Boessenkool ---
Cool, thanks!
121007.c:36:3: warning: 'v4' may be used uninitialized [-Wmaybe-uninitialized]
No clue why it says "may be" there, it obviously *is* used uninitialised,
this is the first time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #8 from Segher Boessenkool ---
(Also tested on powerpc-linux (where things just work), and on powerpc64-linux
(the older ABI, correct-endian), where it fails just the same as on LE).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641
--- Comment #4 from Rich Felker ---
It's a C conformance bug that's been present ever since the version of the
FDPIC support I submitted for merge, so I think it's appropriate for backport
to any branch that's still open and fixing bugs of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #11)
> Though even there is uninitialized read I guess from temp.a.
> That said, LRA obviously shouldn't hang even on code which has UB at runtime.
Of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
--- Comment #4 from Sam James ---
I'll bisect it now, I won't have a chance to try reduce until the weekend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
--- Comment #5 from Sam James ---
(In reply to Sam James from comment #0)
> $ make -j$(nproc) -l$(nproc)
This should read:
$ make -j$(nproc) -l$(nproc) STAGE1_C{,XX}FLAGS="-O3 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
H.J. Lu changed:
What|Removed |Added
Attachment #61827|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641
--- Comment #5 from Oleg Endo ---
(In reply to Rich Felker from comment #4)
> It's a C conformance bug that's been present ever since the version of the
> FDPIC support I submitted for merge, so I think it's appropriate for
> backport to any bra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
--- Comment #11 from Sam James ---
Without -fprofile-generate:
│ 0001ed00 <_Py_Check_ArgsIterable>:
│ _Py_Check_ArgsIterable():
│ mov0x18(%rdx),%rax
│ cmpq $0x0,0xe8(%rax)
│ je 1ed20 <_Py_Check_ArgsIterable+0x20>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #10 from Iain Sandoe ---
(In reply to Jason Merrill from comment #9)
> (In reply to Jason Merrill from comment #8)
> > Iain, will you backport r16-1507?
>
> Actually, I'll do it.
that's fine too - my plan is to back port the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121013
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
Bug ID: 121016
Summary: coroutine appears to be allergic to {()}
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121019
Bug ID: 121019
Summary: Explore removal of DI patterns for rv32
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-07-09
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
--- Comment #5 from Žarko Asen ---
in my case (C++ 20) -Wunitialized was not enabled by -Wall therefore a
critical bug slip through:
const uint32_t x = x + 1; // where is a novel variable in the local and
global scope
This should have been cau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #4 from Marc Singer ---
I found that there are cases in the same program where it does compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #3 from Andrew Pinski ---
I think you could just use do { } while(0) instead of a statement expression
here.
That is:
#define COTHREAD_PROTOTHREAD(f) do {\
using namespace Glow::Cothreads;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #5 from Andrew Pinski ---
(In reply to Marc Singer from comment #4)
> I found that there are cases in the same program where it does compile.
Yes there might be some cases where statement expressions will work but we know
there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #6 from Marc Singer ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Marc Singer from comment #4)
> > I found that there are cases in the same program where it does compile.
>
> Yes there might be some cases where stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121017
Bug ID: 121017
Summary: `__builtin_copysign(0.0, a)` should be optimized to
0.0 for -fno-signed-zeros
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121017
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004
--- Comment #8 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #7)
> And obviously for -fno-signed-zeros optimize the copysign to just 0.
Filed as PR 121017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119328
--- Comment #3 from eczbek.void at gmail dot com ---
This no longer appears to ICE but still errors: https://godbolt.org/z/699vW5dhn
1 - 100 of 129 matches
Mail list logo
