---
htdocs/gcc-15/changes.html | 20
1 file changed, 20 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index a02ba17a..b94802f5 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -842,6 +842,26 @@ asm (".text;
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-15.1-
On 2/3/25 2:40 AM, Richard Biener wrote:
On Fri, Jan 31, 2025 at 7:10 PM Aleksandar Rakic
wrote:
From: Mihailo Stojanovic
This looks like a target specific hack, this should be addressed generally
instead of opening up gcse internals to a target hook.
This should also at least come with
Disallow adding new symbols to GLIBCXX_3.4.34 and CXXABI_1.3.16 versions.
* testsuite/util/testsuite_abi.cc (check_version): Update latestp
to use GLIBCXX_3.4.35 and CXXABI_1.3.17.
---
libstdc++-v3/testsuite/util/testsuite_abi.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
On Thu, 17 Apr 2025, Tobias Burnus wrote:
> * https://gcc.gnu.org/projects/gomp/
This is a no-brainer. Please go ahead and push (and any such changes in
the future).
It does make me wonder whether we really need/want distinct docs for minor
releases or shouldn't better keep just one for the br
---
htdocs/gcc-15/changes.html | 24
1 file changed, 24 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index a02ba17a..011fc5ca 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -842,6 +842,30 @@ asm ("
ue in a later GCC15 as part of fixes, but until
then please move that to reference as you did with the current standard, not to
"pass".
Note: you may want to include a link to the gcobol manual which is also online
at GCC space.
Simon
I'll change it to "...much of the NIST test suite..." before I push it.
> -Original Message-
> From: Simon Sobisch
> Sent: Thursday, April 17, 2025 15:11
> To: rdub...@symas.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Re: [PATCH] Add COBOL to htdocs
On Thu, 17 Apr 2025, Tobias Burnus wrote:
> Anyone: comments are welcome.
> + The standard C++ library (libstdc++) is now supported
I wouldn't mark up libstdc++ as in this context; we are pretty much
treating it as a proper name/project name.
(Two occurrences.)
Looks good to me otherwise, t
Adds a COBOL section to htdocs/gcc-15/changes.html.
Okay for master?
>From 177e87149b3174ca27a58cef7276d88d1363061b Mon Sep 17 00:00:00 2001
From: Robert Dubner mailto:rdub...@symas.com
Date: Thu, 17 Apr 2025 12:47:26 -0400
Subject: [PATCH] Add COBOL to gcc-15 changes.
* gcc
libstdc++-v3/ChangeLog:
* doc/html/manual/status.html: Regenerate.
* doc/xml/manual/status_cxx1998.xml: Replace references to
mainline GCC.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml
Gerald Pfeifer wrote:
On Thu, 17 Apr 2025, Tobias Burnus wrote:
* https://gcc.gnu.org/projects/gomp/
This is a no-brainer.
Well, it still adds GCC 16 …
It does make me wonder whether we really need/want distinct docs for minor
releases or shouldn't better keep just one for the branch
:
* https://gcc.gnu.org/gcc-15/changes.html
* https://gcc.gnu.org/projects/gomp/
Cheers,
Tobias
Hi all,
@Fortraners: Comments to the added 'do concurrent' item?
@Thomas: Are you fine with this C++ wording?
@Andrew: Likewise for C++ and ROCm bump?
Anyone: comments are welcome.
Affected pages:
* https://gcc.gnu.org/gcc-15/changes.html
* https://gcc.gnu.org/projects/gom
gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
in the PR trail. The fix didn't make it into GCC 15, so this patch
XFAILs the test instead.
Other targets might benefit from an XFAIL too, but people who work on
those targets would be better placed to know the
Status
==
We have reached zero P1 regressions and branched for the GCC 15
release. This leaves trunk which is to become GCC 16 next year
open for general development, Stage 1, again. Please refrain
from disrupting git master too much so that last-minute fixes
for GCC 15.1 can be staged
We have branched for the GCC 15 release. All changes on the releases/gcc-15
branch require release manager approval now.
Quality Data
Priority # Change from last report
--- ---
P1 - 17
P2 580
From: Jeremy Bettis
This patch addresses an issue in the C preprocessor where incorrect
line number information is generated when processing files with a
large number of lines. The problem arises from improper handling
of location intervals in the line map, particularly when locations
exceed LINE
This includes all of the regression fixes that were backported yesterday to GCC
14
and 13 that are also regressions in GCC 12.
Andrew Pinski (6):
phiopt: Reset the number of iterations information of a loop when
changing an exit from the loop [PR117243]
backprop: Fix deleting of a phi
On Wed, Apr 16, 2025 at 01:49:50PM -0500, Robert Dubner wrote:
> I am not well-versed in license and legal issues. But I see that except
> for the GO language, gcc/cobol is almost unique in that there is a LICENSE
> file.
>
> This patch gets rid of it.
>
> Okay for t
These tests were backported from gcc-14 where the testsuite
automatically adds -std=gnu++20 as needed. That doesn't happen on the
older release branches, so an explicit dg-options directive is needed to
ensure the tests are run by default. Otherwise they'll only be run when
somebody use
On 4/14/25 10:24 PM, Alexandre Oliva wrote:
And here's another that came up more recently:
The gcc-14 backport that split the pr114194 testcase for rv32 and rv64
would only generate the expected rv32 sequence if commit
6b315907c0353f71169a7555e653d29a981fef67 had also been backported
I am not well-versed in license and legal issues. But I see that except
for the GO language, gcc/cobol is almost unique in that there is a LICENSE
file.
This patch gets rid of it.
Okay for trunk?
Subject: [PATCH] cobol: Eliminate gcc/cobol/LICENSE. [PR119759]
gcc/cobol
PR cobol
On 4/14/25 10:22 PM, Alexandre Oliva wrote:
On Apr 14, 2025, Jeff Law wrote:
No strong opinion. I'd lean towards xfail or twiddling the test since
that's obviously super-save WRT codegen on the gcc-14 release branch.
Twiddling it is, then (pending approval ;-)
The pr118182-2.
This includes the one which needed some changes to the function (gimple_extract)
being split out from gimple-match-head.cc in GCC 14.
Andrew Pinski (3):
discriminators: Fix assigning discriminators on edge [PR113546]
match: Reject non-ssa name/min invariants in gimple_extract [PR116412
Update the OpenMP entry in the GCC 15 release notes and the status at the
OpenMP project
page.
* https://gcc.gnu.org/gcc-15/changes.html
* https://gcc.gnu.org/projects/gomp/
Tobias
commit 5937699869cfc15d57d8ba5913109701dcf7a64b
Author: Tobias Burnus
Date: Tue Apr 15 23:50:57 2025 +0200
LGTM, thanks :)
Alexandre Oliva 於 2025年4月15日 週二 12:25 寫道：
>
> And here's another that came up more recently:
>
> The gcc-14 backport that split the pr114194 testcase for rv32 and rv64
> would only generate the expected rv32 sequence if commit
> 6b315907c0353f71169a7555e6
OK for GCC 14 branch, thanks :)
On Tue, Apr 15, 2025 at 12:23 PM Alexandre Oliva wrote:
>
> On Apr 14, 2025, Jeff Law wrote:
>
> > No strong opinion. I'd lean towards xfail or twiddling the test since
> > that's obviously super-save WRT codegen on the gcc-14 rele
Just a set of 4 patches backported from the trunk via 14 branch
to the GCC 13 release branch. These all fix regressions.
Andrew Pinski (4):
vec-lowering: Fix ABSU lowering [PR111285]
backprop: Fix deleting of a phi node [PR116922]
phiopt: Reset the number of iterations information of a loop
And here's another that came up more recently:
The gcc-14 backport that split the pr114194 testcase for rv32 and rv64
would only generate the expected rv32 sequence if commit
6b315907c0353f71169a7555e653d29a981fef67 had also been backported, but
it wasn't. Without it, we get the sa
On Apr 14, 2025, Jeff Law wrote:
> No strong opinion. I'd lean towards xfail or twiddling the test since
> that's obviously super-save WRT codegen on the gcc-14 release branch.
Twiddling it is, then (pending approval ;-)
The pr118182-2.c testcase backported from gcc-15 depe
value_replacement for middle bb having phi nodes
[PR118922]
phiopt: Reset the number of iterations information of a loop when
changing an exit from the loop [PR117243]
gcc/testsuite/gcc.dg/torture/pr117243-1.c | 30
gcc/testsuite/gcc.dg/torture/pr117243-2.c | 34 ++
gcc
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-15.1-
-stack
On the GCC side, the user can:
- Enable MTE stack tagging using -fsanitize=memtag
- Select the MTE mode by using -fsanitize-memtag-mode=mode.
TBD:
- We need to check explicitly for stack tagging; sanitize(memtag) does
not appear to be enough. Because -fsanitize=memtag will also be
---
Pushed.
htdocs/gcc-3.2/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-3.2/changes.html b/htdocs/gcc-3.2/changes.html
index 7b9ea63f..4ab9fdce 100644
--- a/htdocs/gcc-3.2/changes.html
+++ b/htdocs/gcc-3.2/changes.html
@@ -59,7 +59,7 @@
C
On 4/10/25 12:34 PM, Jason Merrill wrote:
On 4/8/25 10:29 AM, Patrick Palka wrote:
The template arguments aren't dependent however -- they're just
incomplete because when we deferred them we were in the middle
deduction, and we consider a NULL_TREE template argument as dependent.
I wonder what
checking assert, we go on to correctly merge the
template arguments into {{0, NULL_TREE}, {1, NULL_TREE}}. So this
patch just removes this imprecise assert.
PR c++/119574
gcc/cp/ChangeLog:
* pt.cc (add_extra_args): Remove checking assert.
gcc/testsuite/ChangeLog:
* g++.d
On 4/9/25 3:16 PM, Jakub Jelinek wrote:
Hi!
These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything
Hi Thomas,
Thomas Schwinge wrote:
To allow me to progress with other work items, is the attached
"OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause
[PR119692]"
OK to push to trunk branch, with a few test cases added?
I assume this patch has been wi
Hi!
These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything done through them should be translated
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-15.1-
Hi!
To allow me to progress with other work items, is the attached
"OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause
[PR119692]"
OK to push to trunk branch, with a few test cases added?
(I might also suggest OpenACC 'default(firstprivate)' for
On 4/8/25 10:29 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for the 14 branch?
OK.
-- >8 --
In GCC 14 we fixed PR116567 in a more conservative way that doesn't
distinguish between the two kinds of deferred substitutions, and we
ins
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-15.1-
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
https://translationproject.org
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
https://translationproject.org
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-15.1-
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for the 14 branch?
-- >8 --
In GCC 14 we fixed PR116567 in a more conservative way that doesn't
distinguish between the two kinds of deferred substitutions, and we
instead ICE from get_innermost_template_arg
> Thanks Fernando,
Seconded.
> I've pushed the attached changes.
I have made a few subsequent tweaks (attached).
--
Eric Botcazou
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 8220d130..e29fca9d 100644
--- a/htdocs/gcc-15/changes.html
+++ b/ht
iddle
deduction, and we consider a NULL_TREE template argument as dependent.
If we remove this checking assert, we go on to correctly merge the
template arguments into {{0, NULL_TREE}, {1, NULL_TREE}}. So this
patch just removes this imprecise assert.
PR c++/119574
gcc/cp/ChangeLog:
From: Fernando Oleo Blanco
Co-authored-by: Marc Poulhiès
---
Thanks Fernando,
I've pushed the attached changes.
Marc
htdocs/gcc-15/changes.html | 112 -
1 file changed, 111 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdoc
> From: Gerald Pfeifer
> Sent: Sunday, March 30, 2025 4:23 AM
>
> On Mon, 24 Mar 2025, Haochen Jiang wrote:
> > Mention AVX10.1 option changes, revise AVX10.2 option and mention
> > APX_F new feature in GCC 15.
> > ---
>
> >New ISA extens
On 4/3/25 1:17 AM, Jin Ma wrote:
Hi Jeff,
I have some patches for XThreadVector that I would like to cherry-pick from the
master branch to releases/gcc-14.
I have "Write After Approval" permissions. Is there anything I need to do
before proceeding with the cherry-pick,
or could
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-15.1-
so that we get rid of the warning on the branches.
libstdc++-v3/ChangeLog:
PR libstdc++/116212
*
testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
Use unsigned for vector size.
---
Tested x86_64-linux.
Pushed to gcc-14. I'll also backpor
eck master-aarch64, after:
| commit gcc-15-8972-g7e286b56545
We track this bug report underhttps://linaro.atlassian.net/browse/GNU-1554.
Please let us know if you have a fix.commit e0886d8ad4c51919c349d0b31f2bec3acbc79e14
Author: Tobias Burnus
Date: Sun Mar 30 09:55:29 2025 +0200
gcc/testsu
Tue, Mar 18, 2025 at 12:13 PM Iain Sandoe wrote:
>>>>>
>>>>> tested on x86_64/aarch64 Linux and x86_64-darwin, OK for trunk?
>>>>> thanks
>>>>> Iain
>>>>>
>>>>> --- 8< ---
>>>>
-off-by: Om Swaroop Nayak <96killera...@gmail.com>
---
gcc/rust/ast/rust-collect-lang-items.cc | 7 +--
gcc/rust/util/rust-attributes.cc| 8
gcc/rust/util/rust-attributes.h | 2 ++
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/gcc/rust/ast/rust-
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-15.1-
This was fixed on trunk by r15-4473-g3abe751ea86e34, but that isn't
suitable for backporting. Instead, just add another unreachable
condition in std::vector::_M_range_insert so the compiler knows this
memcpy doesn't use a length originating from a negative ptrdiff_t
converted to a very positive siz
rm.
>
> Question: Is there a reason to have multiple flags for that?
[I think this thread belongs in gcc@ because there's no patch to
discuss. I'm answering here for the sake of continuity.]
-ffixed-form and -ffree-form are the names gfortran uses. To get
"logical referenc
On Sun, Mar 30, 2025 at 04:25:41PM +0200, Mark Wielaard wrote:
> cgit is more efficient compared to gitweb and has nicer URLs. Other
> redirects like gcc.gnu.org/g:x and bugzilla now also redirect to
> cgit.
LGTM.
> diff --git a/cgi-bin/gcc-gitref.cgi b/cgi-bin/gcc-gitref
Hi Gerald,
(Adding Arsen to CC, see below)
On Sat, Apr 05, 2025 at 12:02:44AM +0200, Gerald Pfeifer wrote:
> On Fri, 4 Apr 2025, Mark Wielaard wrote:
> > So I really don't have time to rewrite this to use some other cgi
> > mechanism. Would you mind if we go with the current version?
>
> Apologi
On Fri, 4 Apr 2025, Mark Wielaard wrote:
>>> Might there be a way to do that on the server side (via .htaccess or some
>>> other configuration)?
>> There might be, but it has been more than a decade since I hacked on
>> cgi scripts. I am not sure I can reliably rewrite this one to use some
>> othe
Hi Gerald,
On Mon, 2025-03-31 at 15:27 +0200, Gerald Pfeifer wrote:
> > - echo 'https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h='$ret'">'
> > + echo 'https://gcc.gnu.org/cgit/gcc/commit/?id='$ret'">'
>
> Might th
p=gcc.git;h='$ret'">'
> + echo 'https://gcc.gnu.org/cgit/gcc/commit/?id='$ret'">'
Might there be a way to do that on the server side (via .htaccess or some
other configuration)?
Gerald
Hi Gerald,
On Mon, 2025-03-31 at 17:32 +0200, Mark Wielaard wrote:
> On Mon, 2025-03-31 at 15:27 +0200, Gerald Pfeifer wrote:
> > > - echo 'https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h='$ret'">'
> > > + echo 'https://gcc.gnu.org/cgit/gcc
---
Changes for https://gcc.gnu.org/gcc-15/changes.html#libstdcxx
Are we missing anything else significant?
htdocs/gcc-15/changes.html | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index c80ecc50..b23c7e74
From: Jeremy Bettis
This patch addresses an issue in the C preprocessor where incorrect
line number information is generated when processing files with a
large number of lines. The problem arises from improper handling
of location intervals in the line map, particularly when locations
exceed LINE
On Tue, Apr 1, 2025 at 11:32 AM Jonathan Wakely wrote:
> This was fixed on trunk by r15-4473-g3abe751ea86e34, but that isn't
> suitable for backporting. Instead, just add another unreachable
> condition in std::vector::_M_range_insert so the compiler knows this
> memcpy doesn't use a length origi
Alfie Richards writes:
> Minor update to add the PR label from Alex's feedback (thank you!).
>
> Regtested and bookstrapped for gcc-12 and gcc-13 (after applying
> r13-100-g3771486daa1e904ceae6f3e135b28e58af33849 to gcc-12).
>
> Alfie
>
> Andrew Carlotti (1):
>
> From: Gerald Pfeifer
> Sent: Sunday, March 30, 2025 5:23 AM
>
> On Mon, 24 Mar 2025, Haochen Jiang wrote:
> > Mention AVX10.1 option changes, revise AVX10.2 option and mention
> > APX_F new feature in GCC 15.
> > ---
>
> >New ISA extens
Hi, is there any feedback that I should apply? If not, I would like to
see the patch merged so that people can see the changes for Ada :)
Best regards,
Fer
On 3/24/25 19:47, Fernando Oleo Blanco wrote:
> Dear GCC maintainers,
>
> I have written the GCC 15 changelog for Ada. I am atta
cgit is more efficient compared to gitweb and has nicer URLs. Other
redirects like gcc.gnu.org/g:x and bugzilla now also redirect to
cgit.
---
cgi-bin/gcc-gitref.cgi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cgi-bin/gcc-gitref.cgi b/cgi-bin/gcc-gitref.cgi
index
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-15.1-
On 3/29/25 5:56 PM, LIU Hao wrote:
This is a minor change, bootstrapped on x86_64-w64-mingw32.
Thanks, applied to master branch as obvious/trivial.
On Mon, 24 Mar 2025, Haochen Jiang wrote:
> Mention AVX10.1 option changes, revise AVX10.2 option and mention
> APX_F new feature in GCC 15.
> ---
>New ISA extension support for Intel AVX10.1 was added.
> - AVX10.1 intrinsics are available via the -mavx10.1 or
> -
This is a minor change, bootstrapped on x86_64-w64-mingw32.
--
Best regards,
LIU Hao
From 83c3e90432f9ebc97785d81be7a94066d9923920 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Sat, 29 Mar 2025 22:47:54 +0800
Subject: [PATCH] gcc/mingw: Align `.refptr.` to 8-byte boundaries for 64-bit
targets
On 3/27/25 7:49 AM, Xi Ruoyao wrote:
I'm proposing the backport to fix an ICE building gegl on powerpc64le:
https://gcc.gnu.org/PR119340. Bootstrapped and regtested on
powerpc64le-linux-gnu, OK for releases/gcc-14?
OK for me. Thank you for working on PR119340.
gcc/lra-constrain
This patch updates both https://gcc.gnu.org/gcc-15/changes.html#openmp and
https://gcc.gnu.org/projects/gomp/ for the current OpenMP implementation status.
It also fixes a typo and intents to actually commit the change that mentions
the support for aarch64 to nvptx offloading,
cf. https
,
> Iain
>
> --- 8< ---
>
> This adds an implementation of memrchr to libiberty and arranges
> to configure gcc to use it, if the host does not have it.
>
> gcc/ChangeLog:
>
> * config.in: Regenerate.
> * configure: Regenerate.
> * co
HO:It's wrong.
Scratch registers generated by LRA also have to be reused.
The patch is very simple.
On x86_64, it bootstraps+regtests fine.
gcc/
PR target/116550
PR target/119340
* lra-constraints.cc (get_reload_reg): Reuse scratch registers
generated by LRA.
(c
; Tested on x86_64 Linux, Darwin aarch64 Linux, OK for trunk?
> thanks,
> Iain
>
> --- 8< ---
>
> This adds an implementation of memrchr to libiberty and arranges
> to configure gcc to use it, if the host does not have it.
>
> gcc/ChangeLog:
>
> *
optimizaiton and coverage testing, I think it is better to not do
that - the requirements of prime path profiling are rather specific and
expensive to get right.
gcc/ChangeLog:
* Makefile.in (OBJS): Add prime-paths.o, path-coverage.o.
(GTFILES): Add prime-paths.cc, path-coverage.cc
it is better to not do
that - the requirements of prime path profiling are rather specific and
expensive to get right.
gcc/ChangeLog:
* Makefile.in (OBJS): Add prime-paths.o, path-coverage.o.
(GTFILES): Add prime-paths.cc, path-coverage.cc
(GCOV_OBJS): Add graphds.o, prime
requirements of prime path profiling are rather specific and
expensive to get right.
>
> gcc/ChangeLog:
>
> * Makefile.in (OBJS): Add prime-paths.o, path-coverage.o.
> (GTFILES): Add prime-paths.cc, path-coverage.cc
> (GCOV_OBJS): Add graphds.o, prime
This option adds a per-multilib variant that specifies -Os
instead of the default.
Signed-off-by: Keith Packard
---
config-ml.in | 2 +-
gcc/Makefile.in | 32 +++-
gcc/configure| 13 +
gcc/configure.ac | 7 +++
gcc/doc
It seems the new expander triggers a latent issue in sched1 causing
extraneous spills in a different sad variant.
Given how close we are to gcc-15 release, disable it for now.
Since we do want to retain and re-enable this capabilty, manully disable
vs. reverting the orig patch which takes away
On 3/25/25 00:45, Robin Dapp wrote:
>> - "TARGET_VECTOR"
>> + "TARGET_VECTOR && 0"
> Would you mind adding a comment here before committing, maybe even reference
> the PR? Not that we want to keep this around for long anyway but just to
> make
> sure :)
Of course, I pondered the same but the
- "TARGET_VECTOR"
+ "TARGET_VECTOR && 0"
Would you mind adding a comment here before committing, maybe even reference
the PR? Not that we want to keep this around for long anyway but just to make
sure :)
--
Regards
Robin
On 3/20/25 15:03, Alex Coplan wrote:
External email: Use caution opening links or attachments
On 20/03/2025 14:31, Alfie Richards wrote:
Hello,
This is a cherry pick of 20385cb92cbd4a1934661ab97a162c1e25935836 which didn't
apply cleanly
so needed a very minor edit to for it to apply fo
On 3/24/25 2:53 PM, Vineet Gupta wrote:
It seems the new expander triggers a latent issue in sched1 causing
extraneous spills in a different satd variant.
Given how close we are to gcc-15 release, disable it for now.
Since we do want to retain and re-enable this capabilty, manully disable
vs
It seems the new expander triggers a latent issue in sched1 causing
extraneous spills in a different satd variant.
Given how close we are to gcc-15 release, disable it for now.
Since we do want to retain and re-enable this capabilty, manully disable
vs. reverting the orig patch which takes away
Dear GCC maintainers,
I have written the GCC 15 changelog for Ada. I am attaching the patch to
the email. It has already had an initial review by Marc, but feel free
to comment on it and request any changes.
Best regards,
Fernando Oleo BlancoFrom 733eeb430068eb59982c28c43c321db5866685d0 Mon
We need the configure result from the decl check for basename() in the GCC
configuration to match that obtained when configuring libiberty or we get
conflicts when is included in any TU that also includes "system.h"
or "libiberty.h" directly.
PR other/1
The 'basename' implementation can vary with the host platform (e.g. POSIX
c.f. Linux). This is the only current uses of basename() in the source
so convert them to use lbasename() as most other cases do.
gcc/ChangeLog:
* gcov.cc (get_gcov_intermediate_filename): Use lbasename(
Hi all,
This patch will mention recent changes for Intel x86_64 in GCC 14 and 15.
Ok for wwwdocs?
Thx,
Haochen
---
Mention AVX10.1 option changes, revise AVX10.2 option and mention
APX_F new feature in GCC 15.
---
htdocs/gcc-14/changes.html | 12
htdocs/gcc-15/changes.html | 33
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file, 'gcc
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators. The file is available at:
https://translationproject.org/latest/gcc/fr.po
(This file, 'gcc-15.1-
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file, 'gcc
1 - 100 of 1876 matches
Mail list logo
