https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
Jakub Jelinek changed:
What|Removed |Added
CC||bruno at clisp dot org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
Neil Booth changed:
What|Removed |Added
CC||neilb at protonmail dot ch
--- Comment #36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #4 from Andrew Pinski ---
(In reply to Roland Illig from comment #2)
> The ambiguous %t sequences are:
>
> operands to %T/%t must be reg + const_int:
I think this one should be a quoted %T with a quoted %t since that is entered
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101602
--- Comment #9 from GCC Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:2d7e1d6e40a13a5f160b584336795b80f193ec3b
commit r15-9326-g2d7e1d6e40a13a5f160b584336795b80f193ec3b
Author: Tobias Burnus
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #3 from Andrew Pinski ---
%{t,z}{d,i,u,o,x} for gcc-internal-format was added with
r14-8909-g8427290f33d95b .
I can't figure out why those are not being marked as gcc-internal-format .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #17 from Fangrui Song ---
I hope that we just remove this malloc+memset => calloc transformation. Even in
the malloc-dom-memset and memset-postdom-malloc case, calloc might not be an
optimization. It is not worth the extra code comple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
Sam James changed:
What|Removed |Added
Target Milestone|15.0|14.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> r15-7253-gea578dd251eaf6 which was backported as r14-11256-gc061ad5a36ba0c.
> Since that is also C++23 only and dealing with inheritedness of a deduction
> gui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #2 from Roland Illig ---
The ambiguous %t sequences are:
operands to %T/%t must be reg + const_int:
specs %%include syntax malformed after %td characters
specs %%rename syntax malformed after %td characters
specs unknown %% command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
Sam James changed:
What|Removed |Added
Last reconfirmed||2025-04-09
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #12 from Sam James ---
Yes, it started with r14-10655-gb5ed381d05e0ed on releases/gcc-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #1 from Roland Illig ---
I fixed the 2 instances that I found in the German translation and uploaded the
file to the Translation Project.
1: the %s%s%s%s mentioned here
2: a %td that was %ld in the German translation
Several string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
Andrew Pinski changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #7 from Andrew Pinski ---
(In reply to Sam James from comment #2)
> Invalid reduction:
Even this one seems to have worked with GCC 14.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #9 from Andrew Pinski ---
r15-630-g5aaf47cb1987bb which was backported as r14-10221-ga9837934203d41 are
my suspects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
Andrew Pinski changed:
What|Removed |Added
Known to fail||15.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #2 from Sam James ---
Invalid reduction:
```
class QDebug {};
struct QFlags {};
namespace QtPrivate {
template class QFlagsStorage;
template struct QFlagsStorageHelper : {
using QFlagsStorage::QFlagsStorage;
protected:
QFlags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #4 from Andrew Pinski ---
Created attachment 61044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61044&action=edit
Sam's testcase tweaked to be valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71923
--- Comment #3 from Sam James ---
I think H.J. has a bunch of patches to clean this up on x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #3 from Sam James ---
(In reply to Sam James from comment #2)
> Invalid reduction:
On that, it's a 14/15 regression, but let's see what it is like on something
valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
Jason Merrill changed:
What|Removed |Added
CC||eczbek.void at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #9 from Haochen Jiang ---
Proposed change:
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index a9fac011f3d..789c1f1ae54 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119687
--- Comment #1 from Andrew Pinski ---
Recuding.
Note it seems cache related too. In that if I remove some code before the
template instantiation place that is causing the problem, the ICE goes away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430
Bug 107430 depends on bug 119129, which changed state.
Bug 119129 Summary: ICE: in keep_template_parm, at cp/pt.cc:5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119129
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119129
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
Jason Merrill changed:
What|Removed |Added
Summary|[14/15 Regression] Compiler |[14 Regression] Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #17 from Sam James ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Peter Bergner changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #9 from Peter Bergner ---
(In reply to Peter Bergner from comment #8)
> Both messages seem valid, so I think we can probably modify the test case to
> look for both error messages.
This fixes the test case:
diff --git a/gcc/testsuit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
--- Comment #8 from Haochen Jiang ---
After some more consideration, my current plan is to raise an error if
-mno-evex512 is not used with AVX512VL enabled in GCC 14 and GCC 15, since w/o
AVX512VL, we could only use scalar instructions. I suppos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #19 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:94438ca82792063abf05823326695af25ab02d17
commit r15-9325-g94438ca82792063abf05823326695af25ab02d17
Author: Jason Merrill
Date: T
ootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250408 (experimental)
29ed33631f0eb4c88c8b253d5245958304102217 (Gentoo Hardened 15.0. p, commit
3c997ffed4de1d98d745b63d1ef95342800c52f1)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119686
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119686
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119686
Bug ID: 119686
Summary: strlen pass gets confused sometimes with stores
beforehand
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 92155, which changed state.
Bug 92155 Summary: strlen(a) not folded after memset(a, 0, sizeof a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83907
--- Comment #4 from Andrew Pinski ---
*** Bug 92155 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119685
--- Comment #2 from Andrew Pinski ---
Simple workaround is doing:
Foo foo{checked_int(n), checked_int(n*n)};
Instead to get around the parse error issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119685
--- Comment #1 from Andrew Pinski ---
I wonder if this is due to starting to parse as a function declaration and
erroring out but the error should be delayed until a parse error itself happens
with n*n.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
--- Comment #6 from Andrew Pinski ---
This might already be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119685
Bug ID: 119685
Summary: deduction guide sometimes ignored in a function call
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92155
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #2)
> (In reply to Peter Bergner from comment #1)
> > > but the conditions that enable the expansion of
> > > __builtin_scalar_byte_in_set
> > > are those of [power9-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119683
Bug ID: 119683
Summary: [13/14 Regression] recalculating the return value
which was already in the register right before
function return
Product: gcc
Version: 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
Andrew Pinski changed:
What|Removed |Added
See Also||https://reviews.llvm.org/D1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #15 from Andrew Pinski ---
Created attachment 61042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61042&action=edit
Another testcase where we want to still do the combining
My simple patch causes this case not to be done. LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
Jakub Jelinek changed:
What|Removed |Added
CC||roland.illig at gmx dot de
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
Bug ID: 119684
Summary: [15 Regression] Severe bug in german translation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130
Warwick Marangos changed:
What|Removed |Added
CC||Warwick.Marangos@citadelsec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119175
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
Andrew Pinski changed:
What|Removed |Added
See Also||https://reviews.llvm.org/D1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87900
Andrew Pinski changed:
What|Removed |Added
Depends on||83022
See Also|https://gcc.gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #13 from Andrew Pinski ---
Note clang does not check for probability.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #12 from Andrew Pinski ---
Created attachment 61041
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61041&action=edit
Testcases for probability
In the case of dontcombine and maybecombine we should not do the combine of
memset/m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #11 from Vineet Gupta ---
Debug log for the smaller test [1]
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680355.html
It hits the same ABNORMAL_EDGE assert.
- bb 17 has V insns, needing vsetvl - which LCM tries to "bubble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #11 from Andrew Pinski ---
https://inbox.sourceware.org/gcc-patches/f4b5d106-8176-b7bd-709b-d43518878...@acm.org/
Ok, Nathan did submit something similar to my patch in the end and I missed it.
Let me poke at the probility counts bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87900
--- Comment #4 from Andrew Pinski ---
The question now comes should this be handled too:
```
typedef int type;
#define size (4)
type *foo ()
{
type *p = (type *)__builtin_malloc (size*sizeof(type));
type tmp[size] = {};
__builtin_memcpy(p,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.5
Summary|malloc & memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119683
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> Created attachment 61040 [details]
> Patch which needs some comments but is lightly tested and seems to work
>
> This also needs testcases but the patch fixes th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
--- Comment #8 from Andrew Pinski ---
Created attachment 61040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61040&action=edit
Patch which needs some comments but is lightly tested and seems to work
This also needs testcases but the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2017-11-17 00:00:00 |2025-4-8
Assignee|nathan at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #18 from Patrick Palka ---
I think I see what you mean -- for the instantiate_template (and possibly even
coerce_template_parms) call site, we could define and pass a new flag
tf_no_level_lowering instead of tf_partial to tell tsubst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672
--- Comment #11 from Edwin Lu ---
(In reply to Robin Dapp from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > Thanks, I've posted it to gcc-patches in case some CI picks it up too:
> > https://gcc.gnu.org/pipermail/gcc-patches/202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #17 from Patrick Palka ---
(In reply to Jason Merrill from comment #15)
> (In reply to Patrick Palka from comment #12)
> > Substituting into seems like a partial
> > substitution to me. If the lambda itself had any template parame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87900
--- Comment #3 from Andrew Pinski ---
Created attachment 61039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61039&action=edit
Patch which needs full testing, some more comments and testcases
This works for the 2 testcases listed in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #16 from Jason Merrill ---
(In reply to Jason Merrill from comment #15)
> So I suspect we want to split the broader meaning out of tf_partial, so
> places like instantiate_template and normalize_concept_definition can choose
> it wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #15 from Jason Merrill ---
(In reply to Patrick Palka from comment #12)
> Substituting into seems like a partial
> substitution to me. If the lambda itself had any template parameters of its
> own, or autos, we wouldn't want to re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #8 from Tamar Christina ---
(In reply to ktkachov from comment #7)
> Could this be extended to scale Neon intrinsics code to SVE by
> re-vectorising and treating the 128-bit Neon lane as a Q-word element of a
> wider SVE vector? I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #5 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> (In reply to Peter Bergner from comment #1)
> > > but the conditions that enable the expansion of
> > > __builtin_scalar_byte_in_set
> > > are those of [po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #6 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #5)
> This needs splitting up in parts. Maybe then some parts can be correct,
> even!
Of course that requires explanatory comments in the patch submission
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #4 from Segher Boessenkool ---
Hi Alex,
(In reply to Alexandre Oliva from comment #0)
> This raises a number of problems:
>
> - instructions and expanders for these builtins don't have their conditions
> tested, so they must necess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
--- Comment #6 from Jonathan Wakely ---
I think it's referring to control-flow problems and data-flow problems, but
maybe I'm wrong about that. I'm not sure what a warning about control is, but I
know what control flow is
Also, I think the origi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119661
--- Comment #3 from Andrew Pinski ---
I am thinking r9-276-g79e7b1fe3290f3 but that was backported to GCC 7.4.0 but
GCC 7.4.0 rejects it still so I am not sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119661
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119668
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119661
--- Comment #1 from Andrew Pinski ---
>Who is correct? (Please elaborate by quoting the C++ standard.)
Most likely NOT GCC. Since EDG, MSVC and clang all agree this is ill-formed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #2 from Peter Bergner ---
(In reply to Peter Bergner from comment #1)
> > but the conditions that enable the expansion of __builtin_scalar_byte_in_set
> > are those of [power9-64], namely TARGET_MODULE && TARGET_POWERPC64.
> I beli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119682
Bug ID: 119682
Summary: reference-modification (temporary literal?) yields
wrong result
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119681
--- Comment #12 from Artemiy Volkov ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Artemiy Volkov from comment #10)
> >
> > CMIIW, but this live range splitting is done a bit later by web and works
> > well in the case where th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119682
--- Comment #1 from Simon Sobisch ---
Created attachment 61038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61038&action=edit
original program showing the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119681
--- Comment #11 from Andrew Pinski ---
(In reply to Artemiy Volkov from comment #10)
>
> CMIIW, but this live range splitting is done a bit later by web and works
> well in the case where those pseudos' live ranges can be split without
> changi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Nicolas Boulenguez changed:
What|Removed |Added
Attachment #59360|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112632
Patrick Palka changed:
What|Removed |Added
CC||nlebedenko at hotmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119681
--- Comment #10 from Artemiy Volkov ---
(In reply to Andrew Pinski from comment #9)
> Note I think the bigger issue is the RTL unroller does do introduce new
> pseudo registers when it is copying basic blocks and does not do live range
> splitti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
--- Comment #4 from Jonathan Wakely ---
Would "efficacy of warnings about control- and data-flow" with an extra hyphen
be better?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101587
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
--- Comment #5 from sandra at gcc dot gnu.org ---
Hmmm, I was using "control" as a noun, e.g. warnings about control and warnings
about data-flow problems, not half of a compound adjective. If that seems
incorrect, of course I can make another at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119671
Jonathan Wakely changed:
What|Removed |Added
Known to fail||13.3.0, 14.2.0
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90468
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119671
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:6c61f43b8cd410125026429a6ea87308dd49a786
commit r13-9500-g6c61f43b8cd410125026429a6ea87308dd49a786
Author: Jonathan Wake
1 - 100 of 202 matches
Mail list logo
