---
> From: Robert Dubner
> Sent: Monday, June 9, 2025 19:19
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] gcc: Make int n_infiles local to gcc.cc.
>
> In the course of stamping out cppcheck warnings, we ran across a complaint
> about a "shadowed variable."
>
slightly tweak the word here just like what
we did in GCC13 for Sierra Forest.
Ok for gcc-wwwdocs?
Thx,
Haochen
---
htdocs/gcc-15/changes.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 5d35253a..d0b289e1
It occurs to me that with 500 or so messages a day coming through, perhaps
targeting individuals might be useful.
Consider this somewhere between an initial message and a ping:
-Original Message-
From: Robert Dubner
Sent: Monday, June 9, 2025 19:19
To: gcc-patches@gcc.gnu.org
Subject
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 Spanish team of translators. The file is available at:
https://translationproject.org/latest/gcc/es.po
(This file, 'gcc-15.
From: Eric Botcazou
In particular the most recently added ones, namely -Og and -Oz. But -Ofast
is not documented because it disregards strict compliance with standards.
gcc/ada/ChangeLog:
* usage.adb (Usage): Justify the documentation of common switches
like that of other
On Tue, Jun 10, 2025 at 1:19 AM Robert Dubner wrote:
>
> In the course of stamping out cppcheck warnings, we ran across a complaint
> about a "shadowed variable."
>
> It turns out that a variable declared in gcc/gcc/h as "extern int
> n_infiles;" is use
First real entries for https://gcc.gnu.org/gcc-16/changes.html
New API routines for OpenMP and OpenACC
Added one supported and one partial to
https://gcc.gnu.org/projects/gomp/
(Once a bit more is implemented, the partial one [declare mapper]
will be also be added to gcc-16/changes.html and
In the course of stamping out cppcheck warnings, we ran across a complaint
about a "shadowed variable."
It turns out that a variable declared in gcc/gcc/h as "extern int
n_infiles;" is used only locally in gcc/gcc/cc.
This change makes that variable "static int n_infil
Hmm okay. Doesn't seem to work for me on latest master at least.
Here's the error i'm getting with makeinfo 4.13:
../../gcc/doc//invoke.texi:249: warning: unlikely character , in @var.
../../gcc/doc//invoke.texi:3801: warning: unlikely character , in @var.
../../gcc/doc//i
On 6/7/25 4:11 AM, Henrik Lindström wrote:
The build fails with older versions.
Signed-off-by: Henrik Lindström
---
gcc/configure| 2 +-
gcc/configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
I think that was just a bug in our documentation that was subsequently
this patch needs further modifications!
Best regards,
Yuao
0001-gcc-middle-end-opt-for-trigonometric-pi-based-functi.patch
Description: 0001-gcc-middle-end-opt-for-trigonometric-pi-based-functi.patch
The build fails with older versions.
Signed-off-by: Henrik Lindström
---
gcc/configure| 2 +-
gcc/configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index 776b0628c60..632fa6cb864 100755
--- a/gcc/configure
+++ b/gcc/configure
Status
==
The gcc-12 branch open for regression and documentation fixes.
We plan to close the branch with the release of GCC 12.5 where
a release candidate is planned at Jul 4th and the release a
week after, Jul 11th. Note that since this is going to be
the last release from the branch it&#
On 6/2/25 5:44 PM, Andrew Pinski wrote:
From: Gwenole Beauchesne
Handle '#pragma GCC optimize' earlier as the __OPTIMIZE__ macro may need
to be defined as well for certain usages. Add additional tests for the
'#pragma GCC target' case with auto-vectorization enabled and m
with older MPFR versions.
While conditionally optimizing these built-in functions based on the available
MPFR version seems beneficial, it poses a testing challenge. Specifically, test
cases would need a mechanism to dynamically determine the MPFR version in use.
Yuao
0001-gcc-middle-e
Joseph Myers wrote:
On Sun, 1 Jun 2025, Yuao Ma wrote:
For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly
From: Gwenole Beauchesne
Handle '#pragma GCC optimize' earlier as the __OPTIMIZE__ macro may need
to be defined as well for certain usages. Add additional tests for the
'#pragma GCC target' case with auto-vectorization enabled and multiple
combinations of namespaces and/or cl
On Sun, 1 Jun 2025, Yuao Ma wrote:
> For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly less
luded our own folding functions.
I've also added tests to ensure everything works as expected.
Best regards,
Yuao
0001-gcc-middle-end-opt-for-trigonometric-pi-based-functi.patch
Description: 0001-gcc-middle-end-opt-for-trigonometric-pi-based-functi.patch
The documentation of which standard C library facilities (headers) are
provided by GCC, as being those required of freestanding
implementations, is reasonably accurate for C99 and before (if you
ignore the provision of for non-GNU targets). It's less
accurate for C11, since we provide alt
Status
==
The GCC 14 branch is open again for regression and documentation fixes.
Quality Data
Priority # Change from last report
--- ---
P10- 1
P2 603- 15
P3 133+ 23
---
Jakub poined out I'd forgotten the #cxx20-iterators on the new link.
And I've just realised it's a fragment not an anchor, so the commit
message is wrong, oops.
Pushed to wwwdocs.
htdocs/gcc-14/porting_to.html | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff
On Thu, 2025-05-22 at 23:55 +0800, Dongsheng Song wrote:
> Hi Kito,
>
> You mentioned that GCC 14 added TLSDESC support for RISC-V and that it
> requires glibc 2.40 [1].
> However, when I looked for relevant information, I found that
> LoongArch and RISC-V both published T
Hi Kito,
You mentioned that GCC 14 added TLSDESC support for RISC-V and that it
requires glibc 2.40 [1].
However, when I looked for relevant information, I found that
LoongArch and RISC-V both published TLSDESC patches for review at the
last year [2], but only the LoongArch patch was merged into
On 20/05/2025 05:26, Alexandre Oliva wrote:
> The backport of commit 205515da82a2914d765e74ba73fd2765e1254112 to
> gcc-14 as 8b1146fe46e62f8b03bd9ddee48995794e192e82, rewriting
> gcc.target/arm/fp16-aapcs-[1234].c into check-function-bodies, requires
> the following patch for the o
On Tue, 20 May 2025 at 06:27, Alexandre Oliva wrote:
>
> The backport of commit 205515da82a2914d765e74ba73fd2765e1254112 to
> gcc-14 as 8b1146fe46e62f8b03bd9ddee48995794e192e82, rewriting
> gcc.target/arm/fp16-aapcs-[1234].c into check-function-bodies, requires
> the following pa
restore expectations introduced in
> r15-2160. Alas, r15-2160 mentions an insn_propagation patch that
> enables those specific save/restore insns to be generated, presumably
> r15-1945, and this change is not present in gcc-14, so we get
> different save/restore insns, and the test fai
tion patch that
enables those specific save/restore insns to be generated, presumably
r15-1945, and this change is not present in gcc-14, so we get
different save/restore insns, and the test fails, even after
backporting r15-1035, that allows for single-character function names
in check-function-bod
The backport of commit 205515da82a2914d765e74ba73fd2765e1254112 to
gcc-14 as 8b1146fe46e62f8b03bd9ddee48995794e192e82, rewriting
gcc.target/arm/fp16-aapcs-[1234].c into check-function-bodies, requires
the following patch for the one-character function names used in those
tests. Tested with gcc-14
Hi Jakub,
Thank you for your suggestion. I actually learned from your earlier patch
(https://gcc.gnu.org/cgit/gcc/commit?id=7f940822) and had already planned to
update tree-call-cdce.cc when handling these builtins. Your guidance is much
appreciated!
Best regards,
Yuao
On Wed, May 14, 2025 at 02:22:23PM +, Yuao Ma wrote:
> If approved, I suggest committing this foundational change first. Constant
> folding for these builtins will be addressed in subsequent patches.
Note, not just constant folding is needed, but I think the builtins should
be handled in
tree-
On 5/14/25 2:22 PM, Joseph Myers wrote:
On Wed, 14 May 2025, Yuao Ma wrote:
Hi Joseph,
I have updated the patch based on your review comments. I added the
newly introduced builtin to extend.texi and mentioned the PR in the
commit message. Could you please take another look when you have a
m
nor parts of the
device ID; they have been around for a long time. Looks like an
include difference exposes them this time around.
https://linux.die.net/man/3/minor
Thanks,
Andrew
>
>
> On Fri, May 16, 2025 at 3:50 PM Songhe Zhu
> wrote:
> >
> > Hi kito
> >
I am surprised that such generic names are defined within the system
header files, I inclined just rename that to major_version,
minor_version, could you send a patch for that?
On Fri, May 16, 2025 at 3:50 PM Songhe Zhu wrote:
>
> Hi kito
> When syncing GCC to the master branch and
* git.html: Note that devel/omp/gcc-15 exists, and that the
corresponding gcc-14 branch is now stale.
---
htdocs/git.html | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 8edaa254..0b55a970 100644
--- a
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 Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This
Status
==
The GCC 14 branch is now frozen for the GCC 14.3 release, a release
candidate is being prepared.
All changes to the branch require release manager approval.
Previous Report
===
https://gcc.gnu.org/pipermail/gcc/2025-April/245990.html
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.
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi Joseph,
>
> I have updated the patch based on your review comments. I added the
> newly introduced builtin to extend.texi and mentioned the PR in the
> commit message. Could you please take another look when you have a
> moment?
This version is OK in t
, May 15, 2025 0:47
To: Yuao Ma
Cc: gcc-patches@gcc.gnu.org ; fort...@gcc.gnu.org
; tbur...@baylibre.com
Subject: Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi all,
>
> This patch adds trigonometric pi-based functio
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi all,
>
> This patch adds trigonometric pi-based functions as gcc builtins: acospi,
> asinpi, atan2pi,
> atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
> these functions, which we plan to leverage
On 5/13/25 11:06 AM, Iain Sandoe wrote:
This could not be done as a cherry-pick from the trunk resolution.
Tested on x86_64-darwin, powerpc64le linux sparc9 solaris,
OK for 14.3 ?
thanks
Iain
--- 8< ---
This is a GCC-14 version of the same strategy as used on trunk, but
with the more w
ed on x86_64-pc-linux-gnu.
PR c++/120126
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-ice33.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice33.C | 12
1 file changed, 12 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/l
Hi all,
This patch adds trigonometric pi-based functions as gcc builtins: acospi,
asinpi, atan2pi,
atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
these functions, which we plan to leverage in future gfortran implementations.
The patch includes two test cases to
Patrick noticed that this PR's testcase has been fixed by the patch for
PR c++/114292 (r15-7238-gceabea405ffdc8), more specifically the part
that walks the type of DECL_EXPR DECLs.
This simply adds the case to the testsuite.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/120126
This could not be done as a cherry-pick from the trunk resolution.
Tested on x86_64-darwin, powerpc64le linux sparc9 solaris,
OK for 14.3 ?
thanks
Iain
--- 8< ---
This is a GCC-14 version of the same strategy as used on trunk, but
with the more wide-ranging code cleanups elided.
P
On 13/05/25 10:41 +0100, Tamar Christina wrote:
Hi All,
In PR116140 it was brought up that adding pragma GCC unroll in std::find makes
it so that you can't use a larger unroll factor if you wanted to. This is
because the value can't be overriden by the other unrolling flags such a
Hi All,
In PR116140 it was brought up that adding pragma GCC unroll in std::find makes
it so that you can't use a larger unroll factor if you wanted to. This is
because the value can't be overriden by the other unrolling flags such as
-funroll-loops.
To know whether this should be p
Hi Sandra, hello world,
Sandra Loosemore wrote:
I have created the devel/omp/gcc-15 (aka "OG15") branch, ...
For previous branches we'd been using ChangeLog.omp files paralleling
the normal ChangeLog files, that were updated manually and committed
with the corresponding patch
I have created the devel/omp/gcc-15 (aka "OG15") branch, but not yet
populated it with patches carried over from devel/omp/gcc-14. These
development branches are where we put bleeding-edge versions of OpenMP
and OpenACC features.
For previous branches we'd been using Chan
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.
(proposed) command line options added to ld are:
-z memtag-mode=
-z memtag-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
On Tue, 6 May 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following amends gcc-15/changes.html with a note that reload
> > is going to be removed for GCC 16.
> >
> > OK for www?
> >
> > * htdocs/gcc-15/changes.html: Mark GCC 15 as
Richard Biener writes:
> The following amends gcc-15/changes.html with a note that reload
> is going to be removed for GCC 16.
>
> OK for www?
>
> * htdocs/gcc-15/changes.html: Mark GCC 15 as last release
> supporting reload.
My reading of the threads was that n
On Fri, May 02, 2025 at 12:26:12PM +0200, Richard Biener wrote:
> The following amends gcc-15/changes.html with a note that reload
> is going to be removed for GCC 16.
Thank you! The patches are taking a little time, I gave up on rebasing
what I had, redoing it is less work. Oh well.
&g
The following amends gcc-15/changes.html with a note that reload
is going to be removed for GCC 16.
OK for www?
* htdocs/gcc-15/changes.html: Mark GCC 15 as last release
supporting reload.
---
htdocs/gcc-15/changes.html | 7 +++
1 file changed, 7 insertions(+)
diff --git a
---
htdocs/gcc-15/changes.html | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index f112af58..d851a744 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -1295,7 +1295,28
two (proposed) command line options added to ld are:
> -z memtag-mode=
> -z memtag-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 che
On Tue, 2025-04-29 at 21:51 +0200, Marc Poulhiès wrote:
> Having both an enum and a variable with the same name triggers an
> error with
> gcc 5.
>
> exploded-graph.h:351:29: error: ‘status’ is not a class, namespace,
> or enumeration
>
> gcc/analyzer/ChangeLog:
&g
Having both an enum and a variable with the same name triggers an error with
gcc 5.
exploded-graph.h:351:29: error: ‘status’ is not a class, namespace, or
enumeration
gcc/analyzer/ChangeLog:
* exploded-graph.h (set_status): Rename parameter.
* constraint-manager.cc (bound
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.
Status
==
The gcc-13 branch is open for regression and documentation fixes.
It's time to plan for the GCC 13.4 release following the planned
GCC 14.3 release. The plan is to do a release candidate for GCC 13.4
on Thursday, May 29th, one week after the GCC 14.3 release followed
by the r
Status
==
The GCC 14 branch is open for regression and documentation fixes. We
are planning for the GCC 14.3 release on May 22th which means scheduling
a release candidate on May 15th in about two weeks from now.
Please work through your assigned bugs and regression fixes and
backport fixes
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.
On 4/27/25 2:49 PM, Eric Botcazou wrote:
For Windows x86-32 targets, the Microsoft ABI only guarantees that the
stack is aligned to 4-byte boundaries. GCC knows about the default
alignment of the stack. However, before this commit, it did not realign the
stack unless SSE was also enabled.
When
ywgrit writes:
> I encountered one problem with loop-im pass.
> I compiled the program dhry2reg which belongs to
> unixbench(https://github.com/kdlucas/byte-unixbench).
>
> The gcc used
> gcc (GCC) 12.3.0
>
> The commands executed as following
> make
> ./Run -c -i
> For Windows x86-32 targets, the Microsoft ABI only guarantees that the
> stack is aligned to 4-byte boundaries. GCC knows about the default
> alignment of the stack. However, before this commit, it did not realign the
> stack unless SSE was also enabled.
>
> When a stricter
For Windows x86-32 targets, the Microsoft ABI only guarantees that the stack
is aligned to 4-byte boundaries. GCC knows about the default alignment of the
stack. However, before this commit, it did not realign the stack unless SSE
was also enabled.
When a stricter (larger) alignment is requested
Signed-off-by: Xin Wang
---
gcc/tree-ssa-loop-im.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/tree-ssa-loop-im.cc b/gcc/tree-ssa-loop-im.cc
index 225964c6215..de0450f5192 100644
--- a/gcc/tree-ssa-loop-im.cc
+++ b/gcc/tree-ssa-loop-im.cc
@@ -3355,6 +3355,9
I encountered one problem with loop-im pass.
I compiled the program dhry2reg which belongs to unixbench(
https://github.com/kdlucas/byte-unixbench).
The gcc used
gcc (GCC) 12.3.0
The commands executed as following
make
./Run -c -i 1 dhry2reg
The results are shown below.
Dhrystone 2 using
The temporary variable will not be wrote back to memory as there
is no exit of inifinite loop, so we prohibit applying store motion
on loops with no exits.
Signed-off-by: Xin Wang
---
gcc/tree-ssa-loop-im.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/tree-ssa-loop-im.cc b/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 Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file, 'gcc-15.
Patch has been committed and pushed upstream.
Best,
Arthur
On 4/25/25 4:30 PM, arthur.co...@embecosm.com wrote:
From: Arthur Cohen
Content was validated using the Nu HTML checker per the contributing doc.
---
htdocs/gcc-15/changes.html | 57 ++
1 file
---
htdocs/gcc-15/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 1b7d0e1b..6659574f 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -388,7 +388,7 @@ asm (".text;
I forgot to push this before going on vacation; sorry.
Pushed to trunk.
---
htdocs/gcc-15/changes.html | 260 +++-
htdocs/gcc-15/diag-color-screenshot.png | Bin 0 -> 33062 bytes
2 files changed, 257 insertions(+), 3 deletions(-)
create mode 100644 htdocs/
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.
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
From: Arthur Cohen
Content was validated using the Nu HTML checker per the contributing doc.
---
htdocs/gcc-15/changes.html | 57 ++
1 file changed, 57 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 3e3c6655
precision instructions
>>> +(predefined macro __ARM_FEATURE_SSVE_FP8DOT4,
>>> +enabled by +ssve-fp8dot4)
>>> +
>>> + SVE FP8 multiply-accumulate to half precision and single
>>> precision
>>> +instructio
---
Pushed to wwwdocs.
htdocs/gcc-15/changes.html | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 3cec4ff4..3e3c6655 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15
FEATURE_SSVE_FP8DOT4,
>> +enabled by +ssve-fp8dot4)
>> +
>> + SVE FP8 multiply-accumulate to half precision and single precision
>> +instructions (predefined macro
>> __ARM_FEATURE_SSVE_FP8FMA,
>> +enabled by +ssve-fp8fma)
&g
SVE_VECTOR_OPERATORS==2,
> +enabled by +sve)
> +
> + __fma (in arm_acle.h)
> + __fmaf (in arm_acle.h)
> + __chkfeat (in arm_acle.h)
> +
> +
> + In addition, the following changes have been made to preexisting
> +ACLE features:
MINMAX, but I'll fix that
separately.
---
htdocs/gcc-15/changes.html | 255 -
1 file changed, 254 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index f03e29c8..958cacc1 100644
--- a/htdocs/gcc-15/ch
C and C++ for base Armv8-A, but with some caveats:
>>
>> Although most variadic functions work, the implementation
>>of them is not yet complete.
>>
>> C++ exception handling is not yet implemented.
>>
>>Further work is pl
th some caveats:
>
> Although most variadic functions work, the implementation
>of them is not yet complete.
>
> C++ exception handling is not yet implemented.
>
>Further work is planned for GCC 16.
>
Thanks, it looks good. Maybe it is worth mentioning t
saphira support still
> exists, the tuning for them are mostly removed.
> (scheduler and the tag collision pass was removed).
Ah, yeah, that was deliberate. My take was that, if anyone is going
to care, we shouldn't have removed it. And if no-one is going to care,
there's no point
ing.
>
> armv8-a has been used as the main testing architecture for the new target.
> C++ code with exceptions can be compiled, and it works until an exception
> needs to be handled.
> The current SEH patch series for binutils and GCC covers all SEH cases in the
> Boost library t
On Wed, 23 Apr 2025, Tamar Christina wrote:
> Hi All,
>
> This documents the PFA support in GCC-15.
>
> Ok for master?
OK.
> Thanks,
> Tamar
>
> ---
> diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
> index
> f03e
Hi All,
This documents the PFA support in GCC-15.
Ok for master?
Thanks,
Tamar
---
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index
f03e29c8581f2749a968e592eae2e40ce3ca8521..7fb70b993c56ff43c09aeb7bfaa4479385679dec
100644
--- a/htdocs/gcc-15/changes.html
+++ b
t the pre-RA scheduler is disabled at -O2? (I am
not 100% sure this should be mentioned).
Those are the only 2 I saw missing.
Thanks,
Andrew Pinski
>
> I'll leave a few days for comments.
>
> Thanks,
> Richard
>
> ---
> htdocs/gcc-15/changes.html | 241 +
compiled, and it works until an exception needs
to be handled.
The current SEH patch series for binutils and GCC covers all SEH cases in the
Boost library testing.
Once they are upstreamed, the Boost library test results will be very close for
x64 and aarch64.
Variadic functions mostly work, howeve
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
1 - 100 of 1914 matches
Mail list logo
