On Tue, Apr 22, 2025 at 05:22:47PM +0100, Richard Sandiford wrote:
> We implemented FAMINMAX ACLE support but failed to define the
> associated feature macro.
>
> Tested on aarch64-linux-gnu & pushed to trunk. OK for GCC 15 too?
>
> Sorry for the late patch. I only
Hi!
On Tue, 22 Apr 2025 at 13:55, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression
> wrote:
> > Our automatic CI has detected problems related to your patch(es). Please
> > find some details below.
> >
We implemented FAMINMAX ACLE support but failed to define the
associated feature macro.
Tested on aarch64-linux-gnu & pushed to trunk. OK for GCC 15 too?
Sorry for the late patch. I only noticed this macro was missing while
writing up the GCC 15 changes. It would be good to get it in for
> On 22 Apr 2025, at 15:31, Tamar Christina wrote:
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, April 22, 2025 2:28 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
>> ktkac...@nvidia.co
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, April 22, 2025 2:28 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
> ktkac...@nvidia.com
> Subject: Re: [PATCH] Document AArch64 changes for GCC 15
>
> Tamar Christina
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, April 22, 2025 1:31 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
>> Tamar Christina
>> Subject: [PATCH] Document AAr
On Tue, 22 Apr 2025, Richard Sandiford wrote:
> Ping, since it sounds from irc like the release is coming soon :)
Fine with me.
> Richard Sandiford writes:
> > gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
> > in the PR trail. The fix didn't
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, April 22, 2025 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; ktkac...@nvidia.com;
> Tamar Christina
> Subject: [PATCH] Document AArch64 changes for GCC 15
>
> The list i
Ping, since it sounds from irc like the release is coming soon :)
Richard Sandiford writes:
> 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 t
sting.
I've used the passive tense for most entries, to try to follow the
style used elsewhere.
We don't yet define __ARM_FEATURE_FAMINMAX, but I'll fix that
separately.
How does this look? Anything I missed?
I'll leave a few days for comments.
Thanks,
Richard
---
htdocs/
Hi!
On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression
wrote:
> Our automatic CI has detected problems related to your patch(es). Please find
> some details below.
>
> In bootstrap_check master-arm-check_bootstrap, after:
> | commit gcc-15-9463-gaa3e72f9430
>
e:
> >> >>
> >> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> >> >> This patch fixes that.
> >> >>
> >> >> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
> >&g
d for years.
>> >> This patch fixes that.
>> >>
>> >> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
>> >>
>> >> Ok for both?
>> >
>> > This adds:
>> >
>> > +TLS:8:_ZSt11__once_call@@
On Tue, 22 Apr 2025 at 09:47, Rainer Orth wrote:
>
> Hi Jonathan,
>
> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth
> > wrote:
> >>
> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> >> This patch fixes that.
> >
On Thu, 17 Apr 2025, Robert Dubner wrote:
> Adds a COBOL section to htdocs/gcc-15/changes.html.
There was an extra in there which I just fixed (= pushed).
(The first hunk is just a whitespace change to align more closely with the
rest of the page; the fix is in the second hunk.)
Ger
On Tue, 22 Apr 2025 at 08:28, Rainer Orth wrote:
>
> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
> This patch fixes that.
>
> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
>
> Ok for both?
This adds:
+TLS:8:_ZSt11_
Hi Jonathan,
> On Tue, 22 Apr 2025 at 08:28, Rainer Orth
> wrote:
>>
>> The Linux/sparc64 libstdc++ baselines haven't been updated for years.
>> This patch fixes that.
>>
>> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
>
On Tue, 22 Apr 2025 at 09:04, Jakub Jelinek wrote:
>
> On Tue, Apr 22, 2025 at 09:18:14AM +0200, Rainer Orth wrote:
> > This patch updates the Solaris libstdc++ baselines for GCC 15.1.
> >
> > Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the
>
I just saw that I seemingly have missed to send this patch also to the mailing
list :-(
It was committed to what was back then still mainline GCC 15:r15-9545-g4bff3f0b89af9a Result after the patch:
https://gcc.gnu.org/onlinedocs/libgomp/Foreign-runtime-support-for-AMD-GPUs.html
and
https
On Sat, 19 Apr 2025 at 13:12, Andreas Schwab wrote:
>
> 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.
OK for trunk, thanks.
> ---
> libst
On Tue, Apr 22, 2025 at 09:18:14AM +0200, Rainer Orth wrote:
> This patch updates the Solaris libstdc++ baselines for GCC 15.1.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the
> gcc-15 branch and trunk.
>
> Ok for both?
The Linux/sparc64 libstdc++ baselines haven't been updated for years.
This patch fixes that.
Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk.
Ok for both?
Rainer
--
-
Rainer
This patch updates the Solaris libstdc++ baselines for GCC 15.1.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the
gcc-15 branch and trunk.
Ok for both?
Rainer
--
-
Rainer Orth, Center for
---
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
> -
1 - 100 of 1899 matches
Mail list logo
