On Jul 26 2025, Robert Dubner wrote:
> Follow-up: After poking around on the internet for inspiration, I used
>
> git log
> basepoints/gcc-15~1..HEAD --reverse --grep="^gcc/cobol" --grep="^libgcobol"
> --grep="cobol.dg"
git rev-list --reverse --grep=^cobol --grep=^libgcobol
origin/releases/g
Hi Mikael,
On 7/27/2025 3:57 AM, Mikael Morin wrote:
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
Thanks for the thorough review! I've addressed the comments and attached
a new patch below.
diff --git a/gcc/fortran
Committed as the failures of CI is unrelated.
Pan
-Original Message-
From: Li, Pan2
Sent: Friday, July 25, 2025 10:11 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com; Chen, Ken ; Liu, Hongtao
; Li, Pan2
Subject
On Fri, Jul 25, 2025 at 5:14 AM Jennifer Schmitz wrote:
>
> This patch adds a new tuning model for the NVIDIA Olympus core.
> The values used here are based on the Software Optimization Guide
> that will be published imminently.
>
> Bootstrapped and tested on aarch64-linux-gnu, no regression.
>
>
> -Original Message-
> From: Richard Biener
> Sent: Saturday, July 26, 2025 12:06
> To: Robert Dubner
> Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; James K. Lowden
>
> Subject: Re: GCC 15.1.1 Status Report (2025-07-11)
>
>
>
> > Am 26.07.2025 um 01:31 schrieb Robert Dubner :
> >
>
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index be984271d6a..c2a91c93d28 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
This is a follow-up to:
r16-2248-gac8e536526393580bc9a4339bab2f8603eff8a47
fortran: Delay evaluation of array bounds after reallocation
That revision delayed the evaluation of array bounds, with changes in
two
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
This is a follow-up to revision:
r16-2371-g8f41c87654fd819e48c9f6f1ac3d87e35794d310
fortran: Factor array descriptor references
That revision introduced new variables to limit repeated subexpressions
in array
From: Mikael Morin
PR 121185 exhibited wrong code examples where for assignements such as:
class_obj%non_poly = class_obj%non_poly * x
polymorphic references are (wrongly) used to access the left-hand-side
array.
This is caused by:
1. In the scalarizer, we delay (since r16-2248) evaluation of
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Don't look for a class container too far after an array descriptor.
This avoids generating a polymorphic array reference, using the virtual
table of a parent object, to access a non-polymorphic child having a
t
On Sat, Jul 26, 2025 at 11:57:50PM +0800, Yuao Ma wrote:
>
> On 7/26/2025 11:25 PM, Steve Kargl wrote:
> > On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
> > > + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
> > > + BT_UNKNOWN, 0, GFC_STD_F2023,
> > > + gfc_check_split,
Regrename can fail in some case and `insn_rr[INSN_UID (insn)].op_info`
will be null. The FMA steering code was not expecting the failure to happen.
This started to happen after early RA was added but it has been a latent bug
before that.
Build and tested for aarch64-linux-gnu.
Backported for GCC 1
r15-6789-ge7f98d9603808b added a new RTL pass for hardreg PRE for the hard
register
of FPM_REGNUM, this pass could get expensive if you have a large number of
basic blocks
and the hard register was never live so it does nothing in the end.
In the aarch64 case, FPM_REGNUM is only used for FP8 rela
> -Original Message-
> From: Richard Biener
> Sent: Saturday, July 26, 2025 12:06
> To: Robert Dubner
> Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; James K. Lowden
>
> Subject: Re: GCC 15.1.1 Status Report (2025-07-11)
>
>
>
> > Am 26.07.2025 um 01:31 schrieb Robert Dubner :
> >
> >
__tls_get_addr doesn't preserve vector registers. When a function
with no_caller_saved_registers attribute calls __tls_get_addr, YMM
and ZMM registers will be clobbered. Issue an error and suggest
-mtls-dialect=gnu2 in this case.
gcc/
PR target/121208
* config/i386/i386.cc (ix86
On 11/7/24 10:36 AM, Robin Dapp wrote:
I think it'd be better if I abstain from this. I probably disagree too
much with the current structure and the way that the code is developing.
I won't object if anyone else approves it though.
It's not that I'm happy with the current state either and
> On Jul 24, 2025, at 3:52 PM, Kees Cook wrote:
>
> On Thu, Jul 24, 2025 at 04:26:12PM +, Aaron Ballman wrote:
>> Ah, apologies, I wasn't clear. My thinking is: we're (Clang folks)
>> going to want it to work in C++ mode because of shared headers. If it
>> works in C++ mode, then we have t
> On Jul 23, 2025, at 12:30 AM, Kees Cook wrote:
>
> On Wed, Jul 23, 2025 at 07:47:11AM +0200, Martin Uecker wrote:
>> IMHO there are enough reasons to reject delayed parsing
>> as bad design for C. We should work towards proper
>> language features that cleanly fit into the language,
>> inst
> On Jul 23, 2025, at 2:11 PM, Joseph Myers wrote:
>
> On Wed, 23 Jul 2025, Martin Uecker wrote:
>
>> IMHO there are enough reasons to reject delayed parsing
>> as bad design for C. We should work towards proper
>> language features that cleanly fit into the language,
>> instead of pushing t
After import std, std::byteswap cannot be used.
After my observation, this function is the only one in the header
file that has not been exported.
The purpose of this patch is to export std::byteswap so that it can be used
normally after import std.
Signed-off-by: hexne <61956889+he...@users.nore
> Am 26.07.2025 um 01:31 schrieb Robert Dubner :
>
> Richard, this message of yours about changes for 15.2 RC has been
> percolating in my head since I first saw it.
>
> So, today I gave it a shot.
>
> A significant amount of COBOL development has occurred in the four months
> since GCC-15 w
On 7/22/25 4:19 AM, Konstantinos Eleftheriou wrote:
While scanning the instructions and upon reaching an instruction that
doesn't satisfy the constraints that we have set, we were removing the
already detected stores, but we were continuing adding stores from that
point onward. This was causin
Hi Steve,
On 7/26/2025 11:25 PM, Steve Kargl wrote:
On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
+ add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
+ BT_UNKNOWN, 0, GFC_STD_F2023,
+ gfc_check_split, NULL, gfc_resolve_split,
+ "string", BT_CH
On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
>
> + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
> + BT_UNKNOWN, 0, GFC_STD_F2023,
> + gfc_check_split, NULL, gfc_resolve_split,
> + "string", BT_CHARACTER, dc, REQUIRED, INTENT_IN,
> + "set"
On Sat, 26 Jul 2025, Nathaniel Shead wrote:
> On Fri, Jul 25, 2025 at 08:58:47AM -0400, Patrick Palka wrote:
> > On Fri, 25 Jul 2025, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > I noticed that C++26 trivial r
On 7/23/25 5:41 AM, Aleksandar Rakic wrote:
Public
Hi,
Could you please let us know if you have any comments
on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Monday, March 17, 2025 2:23 PM
To: gcc-patches@gcc.gnu.org
Cc: D
Building with GCC 5, with commit 8d9d9515f5db9bab758e484f3956033150931de5
"diagnostics: move diagnostic.c to diagnostics/context.cc", we got:
../../source-gcc/gcc/diagnostics/context.cc: In member function ‘bool
diagnostics::context::diagnostic_impl(rich_location*, const
diagnostics::metadat
Building with GCC 5, with commit 3cc27ed5b6fb4253d3fe2139dcc6295e85372a3a
"diagnostics: convert diagnostic_t to enum class diagnostics::kind", we got:
../../source-gcc/gcc/diagnostics/option-classifier.cc: In member function
‘diagnostics::kind
diagnostics::option_classifier::update_effective
On 6/12/25 11:03 AM, Alfie Richards wrote:
Adds some aarch64 C fmv diagnostic tests.
This mostly tests C front end code, but has to be target specific at FMV
is requires specifying target extensions.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mv-and-mvc-error1.c: New test.
On 6/12/25 11:03 AM, Alfie Richards wrote:
This patch removes the warning for target_version and target_clones in aarch64
as it is now spec compliant.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_process_target_version_attr):
Remove warning.
* config/aarch64/aa
On 6/12/25 11:03 AM, Alfie Richards wrote:
Add tests covering many FMV errors for Aarch64, including
redeclaration, and mixing target_clones and target_versions.
gcc/testsuite/ChangeLog:
* g++.target/aarch64/mv-and-mvc-error1.C: New test.
* g++.target/aarch64/mv-and-mvc-error
On 6/12/25 11:00 AM, Alfie Richards wrote:
This patch changes the semantics of target_version and target_clones attributes
to match the behavior described in the Arm C Language extension.
The changes to behavior are:
- The scope and signature of an FMV function set is now that of the default
On 6/12/25 10:53 AM, Alfie Richards wrote:
This patch is an overhaul of how FMV name mangling works. Previously
mangling logic was duplicated in several places across both target
specific and independent code. This patch changes this such that all
mangling is done in targetm.mangle_decl_assemb
This patch adds a return statement to M2Exception which removes a
build warning.
gcc/m2/ChangeLog:
* gm2-libs/M2EXCEPTION.mod (M2Exception): Add return
exException in case Raise completes.
(cherry picked from commit db8b92d8d61de408e14a4aebf5a34936699d)
Signed-off-by: Gaius
This is a followup patch for PR modula2/121164 to
fix the location for the error message attributed to cc1gm2.
The Patch has been cherry picked, but without the forced -Wall option
in libgm2.
gcc/m2/ChangeLog:
PR modula2/121164
* gm2-compiler/P1SymBuild.mod: Remove PutProcTypePara
Hi all,
This patch introduces a complete implementation of the SPLIT intrinsic,
including documentation and test cases. While Tobias previously
mentioned that a similar effect could be achieved with existing
functionality, I believe having direct support for this operation won't
cause any iss
From: Pan Li
This patch series would like to support the unsigned SAT_MUL with
the help of mul, instead of the widen_mul. Aka:
NT __attribute__((noinline))
sat_u_mul_##NT##_fmt_1 (NT a, NT b)
{
uint64_t x = (uint64_t)a * (uint64_t)b;
NT max = -1;
if (x > (uint64_t)(max))
return max;
From: Pan Li
Add run and tree-optimized check for mul based unsigned scalar SAT_MUL
instead of the widen_mul.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/sat/sat_u_mul-run-1-u16-from-u64.c: Add rv64
target for run.
* gcc.target/riscv/sat/sat_u_mul-run-1-u32-from-u64.c: D
From: Pan Li
Like widen_mul based pattern, we would like introduce the mul based
pattern as well. The pattern is quite simple compares to the
widen_mul, thus add new instead of the for loop in match.pd.
gcc/ChangeLog:
* match.pd: Add mul based unsigned SAT_MUL.
Signed-off-by: Pan Li
Thanks, LGTM :)
On Sat, Jul 26, 2025 at 12:47 AM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> The riscv-c-api-doc defines a group ID and and a bit position for some
> extension. Most of them are set in riscv-ext.def, but some are missing
> and one bit position (for Zilsd) is wrong.
Am Freitag, dem 25.07.2025 um 20:07 -0700 schrieb Bill Wendling:
> On Thu, Jul 24, 2025 at 2:53 PM Martin Uecker wrote:
> > Am Donnerstag, dem 24.07.2025 um 14:25 -0700 schrieb Bill Wendling:
> > > On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker wrote:
> > > > Am Donnerstag, dem 24.07.2025 um 14:08
Am Freitag, dem 25.07.2025 um 20:12 -0700 schrieb Bill Wendling:
> On Thu, Jul 24, 2025 at 3:20 PM Martin Uecker wrote:
> > Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling:
> > > > constexpr size_t size = 4;
> > > > struct foo {
> > > > char (*buf)[size] __counted_by(size); //
42 matches
Mail list logo
