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=121022
Bug ID: 121022
Summary: Suboptimal code generation for atomic_thread_fence
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
Michael Meissner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 121021, which changed state.
Bug 121021 Summary: Move -Wuninitialized from -Wextra to -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 121021, which changed state.
Bug 121021 Summary: Move -Wuninitialized from -Wextra to -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 121021, which changed state.
Bug 121021 Summary: Move -Wuninitialized from -Wextra to -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-07-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021
Bug ID: 121021
Summary: Move -Wuninitialized from -Wextra to -Wall
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119876
--- Comment #4 from Andrew Pinski ---
Note the difference between what I get with PR 119920 and what LLVM produces is
due to the generation of `b[i] > 0 ? 1 : 2` for GCC; should we file this
seperately?
Jan where you did notice this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
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=121015
H.J. Lu changed:
What|Removed |Added
Attachment #61827|0 |1
is obsolete|
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=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=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=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=121020
--- Comment #3 from Sam James ---
(In reply to Sam James from comment #2)
> Created attachment 61828 [details]
> genrecog.ii.xz
>
> genrecog.o itself is miscompiled.
$ g++ -std=c++14 -c -ggdb3 -o build/genrecog.o /tmp/genrecog.ii -O2
-fno-vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
--- Comment #2 from Sam James ---
Created attachment 61828
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61828&action=edit
genrecog.ii.xz
genrecog.o itself is miscompiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
Sam James changed:
What|Removed |Added
Component|c |tree-optimization
Target Milestone|---
-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --enable-linker-build-id
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib
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=114641
--- Comment #3 from Oleg Endo ---
(In reply to Rich Felker from comment #2)
> The surrounding if statement whose body the hunk modifies is conditioned on
> TARGET_FDPIC, so it should not be able to alter non-FDPIC behavior.
Ah, OK then. I just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #16 from Alexandre Oliva ---
Created attachment 61826
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61826&action=edit
candidate fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641
--- Comment #2 from Rich Felker ---
The surrounding if statement whose body the hunk modifies is conditioned on
TARGET_FDPIC, so it should not be able to alter non-FDPIC behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #13 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #15 from Alexandre Oliva ---
-mlong-calls isn't enough, because with !flag_reorder_blocks_and_partition
arm_long_call_p overrides it to false when functions share the same section.
But with -ffunction-sections I got all the gnat1 so
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=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=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=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=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=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=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=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=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=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 #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=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=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=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=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=119328
--- Comment #3 from eczbek.void at gmail dot com ---
This no longer appears to ICE but still errors: https://godbolt.org/z/699vW5dhn
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=121017
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
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=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=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 #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
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=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=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=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=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=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=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=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 #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=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=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=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=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=121013
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #11 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:2492bab503f57f2cf6e08e5c104f7a1d31d34047
commit r16-2149-g2492bab503f57f2cf6e08e5c104f7a1d31d34047
Author: Jason Merrill
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d1c92ea10d30e4cf359faa8bbe3782ed6173d8a9
commit r16-2148-gd1c92ea10d30e4cf359faa8bbe3782ed6173d8a9
Author: Jason Merrill
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #28 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d1c92ea10d30e4cf359faa8bbe3782ed6173d8a9
commit r16-2148-gd1c92ea10d30e4cf359faa8bbe3782ed6173d8a9
Author: Jason Merrill
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119838
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
--- Comment #18 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:131ba6137bca263d7381ad3331840ee05e306fc9
commit r16-2147-g131ba6137bca263d7381ad3331840ee05e306fc9
Author: Jason Merrill
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:131ba6137bca263d7381ad3331840ee05e306fc9
commit r16-2147-g131ba6137bca263d7381ad3331840ee05e306fc9
Author: Jason Merrill
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119838
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:2ca183c113effe2d334b2227f4fdfa5666db8874
commit r16-2146-g2ca183c113effe2d334b2227f4fdfa5666db8874
Author: Marek Polacek
Date: Tu
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=120870
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #12 from R
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=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
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=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=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=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=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=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
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=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=121015
--- Comment #1 from Sam James ---
I'm reducing it now.
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=121014
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-07-09
CC|
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=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=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=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=121008
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
Keywords|needs-bisection
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
1 - 100 of 129 matches
Mail list logo
