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=120227
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comm
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=118891
--- Comment #27 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:cb2b5471516c3c469f65d927a2a30eb15357e429
commit r16-2049-gcb2b5471516c3c469f65d927a2a30eb15357e429
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #28 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:ec54a14239b12d03c600c14f3ce9710e65cd33f1
commit r16-2052-gec54a14239b12d03c600c14f3ce9710e65cd33f1
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
Richard Sandiford changed:
What|Removed |Added
Summary|[14/15/16 regression] gcc |[14/15 regression] gcc 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120972
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-07-07
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #7 from Martin Jambor ---
(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 from gdb?
>
(gdb) p *f->sym
$5 = {name = 0x7fffbe64a100 "_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
--- Comment #3 from Filip Kastl ---
I've bisected this on Zen2. It is possible that this is actually two different
slowdowns and only the Zen2 slowdown is caused by r16-1647. I'll bisect on
Zen3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #7 from Georg-Johann Lay ---
(In reply to fiesh from comment #6)
> Am I doing something wrong?
Maybe it has to do with LTO. When you are still using -flto, then the object
files only contain LTO byte code except with -ffat-lto-objec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 108585, which changed state.
Bug 108585 Summary: memset uses SSE stores but afterwards does not but if used
"" will use them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
What|Removed
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=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=120955
--- Comment #8 from fiesh at zefix dot tv ---
No, I deactivated lto completely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #14 from Eric Botcazou ---
FWIW the "force functions and their inner functions to remain in a single unit"
approach for LTO was already discussed a few times in the past because of very
similar issues pertaining to the static chain,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120984
Bug ID: 120984
Summary: [16 Regression] Bunch of 'insufficient space for an
object of type...' errors during ubsan bootstrap
Product: gcc
Version: 16.0
Status: UNCONFIRM
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=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=120977
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
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=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=120917
Jason Merrill changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Last reconfirmed|
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=120817
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
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_
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=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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120982
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=120817
--- Comment #15 from Tamar Christina ---
(In reply to Richard Biener from comment #13)
> (In reply to Tamar Christina from comment #12)
> > Looks like the problem is that during ao_ref_init_from_ptr_and_range when
> > initializing vectp_target.1
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=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=120817
--- Comment #17 from Tamar Christina ---
(In reply to Richard Biener from comment #16)
> No, that cannot be required for correct operation. I think DSE is wrong in
> assessing that the store covers more than 5 bytes. The following fixes it
> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120982
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120985
Bug ID: 120985
Summary: Possible memory leak in read_specs at gcc.cc
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: dri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888
--- Comment #7 from jcmvbkbc at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #6)
> You can update xtensa_promote_function_mode to control how to promote
> return value.
I don't think I need to change anything there because the patch tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120985
--- Comment #1 from Jonathan Wakely ---
The memory use and ownership in gcc.cc is a mess. I tried to rewrite everything
to use standard library types and gave up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
Sam James changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #22 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120984
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 120984, which changed state.
Bug 120984 Summary: [16 Regression] Bunch of 'insufficient space for an object
of type...' errors during ubsan bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120984
What
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=120988
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=84009
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:66455591fac1e80b5acc615598cbf556d565e080
commit r16-2046-g66455591fac1e80b5acc615598cbf556d565e080
Author: Jakub Jelinek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #2 from Richard Biener ---
Hmm, I didn't consider the case where the access as the vectorizer views it
(the 4 element "vector") has to be split due to target implementation concerns.
We do not want to introduce additional code genera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119703
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120979
--- Comment #4 from Richard Biener ---
I guess we miss a memdup, using strndup instead of strdup might be a small
improvement.
I don't think inlining it is a good thing to do, this should be addressed
at the library level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120968
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-07-07
Ever confirmed|0
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=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 #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=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=120817
--- Comment #13 from Richard Biener ---
(In reply to Tamar Christina from comment #12)
> Looks like the problem is that during ao_ref_init_from_ptr_and_range when
> initializing vectp_target.14_54 = &targetD.4595 + _55;
>
> we don't enter the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Summary|[12/13/14/15 Regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
Richard Biener changed:
What|Removed |Added
Assignee|tnfchris at gcc dot gnu.org|rguenth at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120670
--- Comment #4 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:401199377c50045ede560daf3f6e8b51749c2a87
commit r16-2047-g401199377c50045ede560daf3f6e8b51749c2a87
Author: H.J. Lu
Date: Tue Jun 17 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120683
--- Comment #5 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:401199377c50045ede560daf3f6e8b51749c2a87
commit r16-2047-g401199377c50045ede560daf3f6e8b51749c2a87
Author: H.J. Lu
Date: Tue Jun 17 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 120683, which changed state.
Bug 120683 Summary: vector_loop/unrolled_loop generates poor codes on
memset/memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120683
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120683
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|12.5|13.5
--- Comment #22 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
--- Comment #2 from Hongtao Liu ---
I've tested my commit(r16-1647) and the previous commit(r16-1646) with
-march=native -Ofast on zen3 server, and didn't find any regression for
503.bwaves_r.(we don't have zen2 machine.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120962
--- Comment #3 from Markus ---
I tried version 15.1. In this case the code compiles.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120985
Richard Biener changed:
What|Removed |Added
Keywords||memory-hog
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
--- Comment #6 from GCC Commits ---
The master branch has been updated by Tomasz Kaminski :
https://gcc.gnu.org/g:2a82d4c859bd0eca4fe31fc79d234abd05e6a9d8
commit r16-2056-g2a82d4c859bd0eca4fe31fc79d234abd05e6a9d8
Author: Tomasz KamiÅski
Date:
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=120986
--- Comment #1 from Alfie Richards ---
Improved reproducer (https://godbolt.org/z/axcc4vzxn)
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=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
--- 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=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=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=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=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=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=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=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=120730
James K. Lowden changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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=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=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=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 #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=116332
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
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=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=120929
Sam James changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=120978
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail d
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=120987
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #6 from And
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=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=119930
Jason Merrill changed:
What|Removed |Added
Component|c++ |tree-optimization
--- Comment #13 from
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:
1 - 100 of 161 matches
Mail list logo
