https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116369
--- Comment #19 from GCC Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:2fd6f42c17a8040dbd3460ca34d93695dacf8575
commit r16-2084-g2fd6f42c17a8040dbd3460ca34d93695dacf8575
Author: François Dumont
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120985
--- Comment #4 from Shuhao ---
I'm relatively new to GCC code bases. Are files like `gcc/*.cc` also parts of
the short-lived driver code? If so, I'll then stop reporting memory leak issues
within these source files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
--- Comment #4 from Rohan Suri ---
Thanks for looking into it Andrew. Good to know that those compiler flags do
catch it.
> I am not sure if a warning is even wanted here. This is just one bad symptoms
> of std::function.
I don't know if GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324
Andrew Pinski changed:
What|Removed |Added
Depends on||119920
--- Comment #9 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119876
Andrew Pinski changed:
What|Removed |Added
Depends on||119920
--- Comment #3 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920
Andrew Pinski changed:
What|Removed |Added
Attachment #61814|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120991
Bug ID: 120991
Summary: ICE on x86_64-linux-gnu: in composite_type, at
c/c-typeck.cc:1006 with transaction_safe
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635
--- Comment #8 from Julian Waters ---
Wait, I just realized this isn't the bug that was reported for 32 bit MinGW. My
comment can be ignored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120227
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120657
--- Comment #1 from Halalaluyafail3 ---
The wrong token being pointed to also occurs when using restrict normally, for
example:
void(*restrict x)()=0;
This generates the error message:
:2:5: error: invalid use of 'restrict'
2 | void(*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #3 from Krister Walfridsson ---
(In reply to Richard Biener from comment #2)
> We do not want to introduce additional code generation overhead to avoid a
> fully out-of-bounds but known not trapping because it's known to fall into
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #461 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #460)
> Oleg, would it make sense to rebase your branch on git.gcc.org with master,
> add all the tests from your tree on Github and then bootstrap gcc native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
--- Comment #3 from Andrew Pinski ---
I am not sure if a warning is even wanted here. This is just one bad symptoms
of std::function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
--- Comment #2 from Andrew Pinski ---
>Interestingly, if I try this on ARM 32-bit GCC 15.1, it does report:
That is because long is 32bit so there is a warning at the function definition
rather than at the function call point.
::function only with -Wsystem-headers which turns on a lot of conversion
warnings outside of std::function):
/opt/compiler-explorer/arm64/gcc-trunk-20250707/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/include/c++/16.0.0/bits/invoke.h:116:42:
warning: conversion from 'long unsigned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
Bug ID: 120990
Summary: Narrowing conversion in std::function return value is
not reported
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120642
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120920
--- Comment #1 from Jeffrey A. Law ---
This looks fairly painful to capture in a backend pattern; I didn't see any
particular attempt by combine that looked like a promising target pattern.
I suspect you'll need to look at a simplify-rtx simpli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930
Jason Merrill changed:
What|Removed |Added
Component|c++ |tree-optimization
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116332
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Created attachment 61814 [details]
> First prototype
>
> Has some rough edges (extra dumps for quick debugging; it also does not
> handle commutative operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120621
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from James K. Lowden ---
> Please advise if this PR can be closed, or if not what flags to use as a
> standard.
There are more errors on 32-bit Darwin. I've posted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
Sam James changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #24 from qinzhao at gcc dot gnu.org ---
I have reverted the patches that triggered the issue.
will fix this issue in the next commit with the new patch set.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920
--- Comment #6 from Andrew Pinski ---
Created attachment 61814
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61814&action=edit
First prototype
Has some rough edges (extra dumps for quick debugging; it also does not handle
commutative ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662
--- Comment #9 from Jonathan Wakely ---
(In reply to Antoine Pitrou from comment #7)
> It seems this comment is mistaken as GCC 13.3, at least, still uses
> pthread_once for std::call_once:
>
> > This should be fixed in GCC 11 which no longer us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ed912b1ee5ad0f241f968d5fd1a54a7e9e0e20dd
commit r16-2078-ged912b1ee5ad0f241f968d5fd1a54a7e9e0e20dd
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #3 from Edwin Lu ---
(In reply to Tamar Christina from comment #2)
> Looks like it's because a very high VF was chosen
>
> optimized: loop vectorized using masked 1024 byte vectors and unroll factor
> 256
> Updating vectorization fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120621
--- Comment #11 from James K. Lowden ---
I would like to close this issue or fix what remains. It was reopened because
it broke the bootstrap build, a lesson sorely learned. With the commit of June
20, that's been fixed.
As of today, using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #28 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:3e34c54d72f6e3723601bcd936409af4a42d17b8
commit r16-2072-g3e34c54d72f6e3723601bcd936409af4a42d17b8
Author: H.J. Lu
Date: Wed Jul 2 08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Jeffrey A. Law changed:
What|Removed |Added
CC||tamar.christina at arm dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Bug 116242 depends on bug 116686, which changed state.
Bug 116686 Summary: [15/16 Regression] RISC-V:
gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 116686, which changed state.
Bug 116686 Summary: [15/16 Regression] RISC-V:
gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #10 from Jeffrey A. Law ---
So I don't mind these changes being tagged to pr119100. My only concern is how
do we know when we're done on this bug?
We don't need to figure it out right now, but we do need to keep that question
in mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
--- Comment #8 from dave.anglin at bell dot net ---
On 2025-07-07 7:43 a.m., tkaminsk at gcc dot gnu.org wrote:
> --- Comment #7 from Tomasz Kamiński ---
> The issue should be addressed now.
Fixes build on hppa64-hp-hpux11.11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119331
--- Comment #4 from Simon Sobisch ---
I see, so I guess you'll leave enabling in the command line interface for now
and autogen+include a temporary CDF for disabling in cobcd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120960
--- Comment #3 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f555ee597ac4fa522da798e9c6a966903a5b7113
commit r16-2071-gf555ee597ac4fa522da798e9c6a966903a5b7113
Author: Martin Jambor
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
Sam James changed:
What|Removed |Added
Attachment #61749|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120730
James K. Lowden changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119331
--- Comment #3 from James K. Lowden ---
This patch awaits work on the command-line interface for warnings and options.
As of now, ECs can be turns on and off via CDF, but can be enabled only via the
command-line. That puts the compiler in compl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-07-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120930
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2025-07-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #9 from Martin Jambor ---
(In reply to Andrew Pinski from comment #6)
> I suspect this just exposes the latent issue. This pushes for more SRA on
> some arguments.
Specifically those where ipa-modref says it is safe - that can be
be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #8 from anlauf at gcc dot gnu.org ---
(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 w".
> > Can you show f->sym and f->sym-attr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #8 from Tom de Vries ---
(In reply to Andrew Pinski from comment #7)
> Question does it just happen on x86_64-linux-gnu or can it be reproduce on
> aarch64-linux-gnu or powerpc64-linux-gnu too?
Reproduced on Fedora Linux Asahi Remix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888
--- Comment #8 from GCC Commits ---
The master branch has been updated by Max Filippov :
https://gcc.gnu.org/g:2a6ac385076a0d43a529e84e7f7ebcbfc3831437
commit r16-2069-g2a6ac385076a0d43a529e84e7f7ebcbfc3831437
Author: H.J. Lu
Date: Tue Jul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120985
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> It's also a short-lived and small binary, not worth the trouble of fixing
> (and making the code more complicated because it's largely C and obstacks
> and manu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
--- Comment #7 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #6 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120670
--- Comment #6 from Ian Lance Taylor ---
FYI I'm going to shortly commit a patch to change to always use C code when
clearing memory. It seems like the only reliable way to avoid the possible use
of "rep stosb", which is valid for C but not alwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #25 from Jason Merrill ---
(In reply to Frank Heckenbach from comment #24)
> auto f (S );
Right, this is one of the cases fixed for GCC 16 by my commit above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117385
--- Comment #7 from Andrew Pinski ---
Note fold_build_cond_expr in tree-ifconv.cc also does this same thing. Though
in that case we won't need the comparison afterwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #24 from Frank Heckenbach ---
(In reply to Jason Merrill from comment #23)
>
> Then yes, it does look like it should work; libstdc++ uses that 'requires
> function call' pattern in
>
> template
> concept __is_derived_from_opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #23 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #21)
> (In reply to Richard Biener from comment #20)
> > so for
> >
> > _1 = _2;
> >
> > we merge from _2. For
> >
> > _1 = *_2;
> >
> > we _a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120989
Andrew Pinski changed:
What|Removed |Added
Depends on||106847
--- Comment #1 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #20 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:4b9f760c511a4ef3a390dd6cfab80bada57c2535
commit r16-2067-g4b9f760c511a4ef3a390dd6cfab80bada57c2535
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662
--- Comment #8 from Sam James ---
(In reply to Antoine Pitrou from comment #7)
For cases like this, a new bug is best, as it's not always the exact same
issue, and in any case is harder to miss in a new bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662
Antoine Pitrou changed:
What|Removed |Added
CC||pitrou at free dot fr
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #23 from Jason Merrill ---
(In reply to Frank Heckenbach from comment #21)
> So my question stands.
Then yes, it does look like it should work; libstdc++ uses that 'requires
function call' pattern in
template
concept __is_der
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119498
Alfie Richards changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119498
--- Comment #1 from GCC Commits ---
The master branch has been updated by Alfie Richards
:
https://gcc.gnu.org/g:5abac04ffc7cc877ff5e1fa6562923b7b05b8289
commit r16-2066-g5abac04ffc7cc877ff5e1fa6562923b7b05b8289
Author: Alfie Richards
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #21 from Frank Heckenbach ---
(In reply to Jason Merrill from comment #20)
> (In reply to Frank Heckenbach from comment #18)
> > So, could this be a viable workaround?
>
> If you're going to modify your code to address this, it seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #22 from Frank Heckenbach ---
(In reply to Frank Heckenbach from comment #21)
> (In reply to Jason Merrill from comment #20)
> > (In reply to Frank Heckenbach from comment #18)
> > > So, could this be a viable workaround?
> >
> > If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
Jason Merrill changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #19 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:8abc2e66be72a34db8c3cc97e4fbd90b7abae61d
commit r16-2065-g8abc2e66be72a34db8c3cc97e4fbd90b7abae61d
Author: Jason Merrill
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120989
Bug ID: 120989
Summary: Shouldn't warn about the use of deprecated non-static
data members in implicit special member functions
Product: gcc
Version: 14.2.1
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120903
andreser-gccbugs at mit dot edu changed:
What|Removed |Added
CC||andreser-gccbugs at mit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117214
--- Comment #10 from GCC Commits ---
The master branch has been updated by Tomasz Kaminski :
https://gcc.gnu.org/g:8ad5968a8dcb472cbff8e4c48217fd65e125b2f2
commit r16-2063-g8ad5968a8dcb472cbff8e4c48217fd65e125b2f2
Author: XU Kailiang
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120988
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
--- Comment #33 from Richard Biener ---
Something like the following might be a testcase, needs -fno-tree-sra
but it fails to demonstrate the particular sub-field layout for Y.
struct X { int *p; int *q; };
struct Y { struct X a; struct { unsig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #19 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:439b14e222571da76da2bfec04b9035fb9f1862d
commit r16-2062-g439b14e222571da76da2bfec04b9035fb9f1862d
Author: Richard Biener
Date:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
connorweston...@yahoo.com
host cleanserver.mxserver.ro [89.44.139.128]
SMTP err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120977
--- Comment #2 from Torbjorn SVENSSON ---
(In reply to Christophe Lyon from comment #1)
> I suppose you all the regressions we also reported in
> https://linaro.atlassian.net/browse/GNU-1596 ?
Looks like it's the same regression yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120988
Bug ID: 120988
Summary: -Wconversion warning for uint /= ulong makes no sense
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
--- Comment #32 from Richard Biener ---
Hmm, or rather the logic is fine, there's simply no field at that offset in the
set of RHS constraints. There's the missing field
$21 = {id = 30, is_artificial_var = 0, is_special_var = 0,
is_unknown_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #8 from fiesh at zefix dot tv ---
No, I deactivated lto completely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2025-05-19 00:00:00 |2025-07-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
--- Comment #30 from Alexander Monakov ---
Forgot to mention that the offending match.pd rule is
/* Simplify pointer equality compares using PTA. */
(for neeq (ne eq)
(simplify
(neeq @0 @1)
(if (POINTER_TYPE_P (TREE_TYPE (@0))
&& p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
Sam James changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
See Al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
--- Comment #29 from Alexander Monakov ---
The above is bisectable on the 'match' dbgcnt, which ends on this transform in
vrp1:
Folding statement: if (e_137 != n_142)
Registering value_relation (e_137 != n_142) on (33->35)
Registering value_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #460 from John Paul Adrian Glaubitz ---
Oleg, would it make sense to rebase your branch on git.gcc.org with master, add
all the tests from your tree on Github and then bootstrap gcc natively to run
the full testsuite to see whether an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #4 from Tom de Vries ---
The problem scenario is as follows.
An error is thrown in symtabs_from_filename:
...
throw_error (NOT_FOUND_ERROR,
_("No symbol table is loaded. "
"Use th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120977
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #3 from Tom de Vries ---
The investigation in the gdb PR has identified a range of bad commits.
First bad commit:
- commit aae723d360c
("sra: SRA of non-escaped aggregates passed by reference to calls")
First good commit after fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #2 from Tom de Vries ---
Workaround:
...
diff --git a/gdb/linespec.c b/gdb/linespec.c
index b59c0553c34..46b25a0047d 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -2615,7 +2615,7 @@ parse_linespec (linespec_parser *parser, cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #2 from Alfie Richards ---
Final reproducer:
```c
#include
svfloat16_t test (svfloat16_t a, svmfloat8_t b, svmfloat8_t c)
{
return svdot_lane_fpm (a, b, c, 0, 0);
}
```
Compiled with `-O2 -march=armv8-a+sve2+fp8dot2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #1 from Tom de Vries ---
Created attachment 61812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61812&action=edit
valgrind log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
Bug ID: 120987
Summary: gdb build with lto triggers use after free
Product: gcc
Version: 14.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #1 from Alfie Richards ---
Improved reproducer (https://godbolt.org/z/axcc4vzxn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
--- Comment #7 from Tomasz Kamiński ---
The issue should be addressed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120985
Richard Biener changed:
What|Removed |Added
Keywords||memory-hog
--- Comment #2 from Richard
1 - 100 of 161 matches
Mail list logo
