Hi,
okay to push? Confirmed that I didn't break anything by running `make html`.
Filip Kastl
-- 8< --
This patch changes two things. Firstly, we document
-fdump-rtl--graph and other such options under -fdump-tree.
At least write a remark about this under -fdump-rtl. Secondly, the
documentati
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
particularly fussed either way.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for t
On Tue, 29 Jul 2025, Robin Dapp wrote:
> > - if (len >= 3
> > + if (!reassoc_insert_powi_p
> > + && len >= 3
> > && (!has_fma
> > /* width > 1 means ranking ops results in better
> > parallelism. Check current value to avoi
This shows reassoc is harmful even with len == 3.
Pushed.
PR tree-optimization/120687
* gcc.dg/vect/pr120687-3.c: New testcase.
---
gcc/testsuite/gcc.dg/vect/pr120687-3.c | 16
1 file changed, 16 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/vect/pr12068
On Tue, Jul 29, 2025 at 09:57:19PM +1000, Nathaniel Shead wrote:
> @@ -7114,8 +7121,10 @@ trees_in::core_vals (tree t)
> }
>
> RT (t->function_decl.personality);
> - RT (t->function_decl.function_specific_target);
> - RT (t->function_decl.function_specific_optimization);
> +
On Tue, 29 Jul 2025, Richard Biener wrote:
> On Tue, 29 Jul 2025, Robin Dapp wrote:
>
> > > - if (len >= 3
> > > + if (!reassoc_insert_powi_p
> > > + && len >= 3
> > > && (!has_fma
> > > /* width > 1 means ranking ops results in better
On Tue, 29 Jul 2025, Pengfei Li wrote:
> Hi Richi,
>
> > But why do we need to reject VLA vectorization for versioning when
> > the target only requires element alignment? I could for example
> > think that arm could have gone with requiring NEON vector size
> > alignment for SVE accesses.
> >
On Tue, Jul 29, 2025 at 02:04:52PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 29, 2025 at 09:57:19PM +1000, Nathaniel Shead wrote:
> > @@ -7114,8 +7121,10 @@ trees_in::core_vals (tree t)
> > }
> >
> > RT (t->function_decl.personality);
> > - RT (t->function_decl.function_specific_targe
Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap+regtest
passes?
-- >8 --
For the sake of determining if there are other errors in user code to
report early, many trait functions don't return error_mark_node if not
called in a SFINAE context (i.e., tf_error is set). This patch remov
On 29/07/2025 10:13, Richard Biener wrote:
On Tue, 29 Jul 2025, Alfie Richards wrote:
(Whoops, s/WIP/RFC)
Hi All,
This patch adds support for capping VF at runtime for VLA loops with a
data dependency.
On 28/07/2025 15:56, Alfie Richards wrote:
Hi All,
This patch adds support for capping VF
Hi Yury,
> -Original Message-
> From: Yury Khrustalev
> Sent: Wednesday, July 23, 2025 9:45 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski ; Richard Sandiford
> ; Tamar Christina ;
> Alfie Richards ; Alice Carlotti
> ;
> Victor Do Nascimento
> Subject: [PATCH v2 3/3] testsuite: Ad
Hey, I am indeed looking for feedback.
Thanks for linking the thread, it is indeed about the same as what I am trying
to achieve.
However, my issue with Jason's suggestion (I've talked about is a bit here too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164) is that it's simply not an
optim
Hi Richi,
> But why do we need to reject VLA vectorization for versioning when
> the target only requires element alignment? I could for example
> think that arm could have gone with requiring NEON vector size
> alignment for SVE accesses.
>
> I do agree that keeping the old check is "safe", but
Hi All,
Quick fixup for the gating (s/&&/|/) for an error I made.
Only needed for trunk as the intrinsics were only added recently.
Bootstrapped and reg tested on Aatch64.
Thanks,
Alfie
-- >8 --
Fixes the feature gating for the SME2+FAMINMAX intrinsics.
PR target/121300
gcc/ChangeLo
> On 29 Jul 2025, at 15:31, Richard Sandiford wrote:
>
> The 8-bit and 16-bit tests in cmpbr.c assumed an inverted operand
> order ("w1, w0"), but it's possible to use the uninverted operand
> order too. This patch generalises the tests to support both forms.
>
> This is a prerequisite for a
Loop peeling and minimal loop vectorization threshold prevented loop
vectorization in these examples. Adjust parameters in the test to
make the test pass.
Tested on s390x. Okay for main and gcc15?
Signed-off-by: Juergen Christ
PR testsuite/121286
PR testsuite/121288
gcc/tests
Hi Richi,
> > > > > diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
> > > > > index 75e06ff28e6..8595c76eae2 100644
> > > > > --- a/gcc/tree-vect-data-refs.cc
> > > > > +++ b/gcc/tree-vect-data-refs.cc
> > > > > @@ -2972,7 +2972,8 @@ vect_enhance_data_refs_alignment (loop_vec_
On Tue, 29 Jul 2025, Alfie Richards wrote:
> On 29/07/2025 10:13, Richard Biener wrote:
> > On Tue, 29 Jul 2025, Alfie Richards wrote:
> >
> >> (Whoops, s/WIP/RFC)
> >>
> >> Hi All,
> >>
> >> This patch adds support for capping VF at runtime for VLA loops with a
> >> data dependency.
> >> On 28/0
Update https://gcc.gnu.org/gcc-16/changes.html for some OpenACC
features that went in; while small and some of them rather new
(OpenACC 3.4 was only released in June 2025), they all show up
in real-world code and, hence, are important to users.
Any comments before (or after) I pushed the changes?
> @4 is now unused, so you could remove it.
Thanks Richard, will commit with this change.
Pan
-Original Message-
From: Richard Biener
Sent: Tuesday, July 29, 2025 2:48 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jeffreya...@gmail.com; rdap
On 28/07/2025 17:13, Richard Sandiford wrote:
Alfie Richards writes:
Hi,
Small fix to resolve an UBSAN diagnostic.
Reg tested for Aarch64
Thanks,
Alfie
-- >8 --
This adds a nullptr check to fix a regression where it is possible to call
`memcmp (NULL, NULL, 0)` which is UB.
This should
> -Original Message-
> From: Pengfei Li
> Sent: Tuesday, July 29, 2025 10:17 AM
> To: Richard Biener ; Tamar Christina
>
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de; s...@gentoo.org
> Subject: Re: [PATCH] vect: Fix insufficient alignment requirement for
> speculative
> loads [PR1211
(Whoops, s/WIP/RFC)
Hi All,
This patch adds support for capping VF at runtime for VLA loops with a
data dependency.
On 28/07/2025 15:56, Alfie Richards wrote:
Hi All,
This patch adds support for capping VF at runtime for VLA loops with a
data dependency.
Previously, no loop with a data depende
Thanks for proof reading and noting the missing patch …
Gerald Pfeifer:
On Tue, 29 Jul 2025, Tobias Burnus wrote:
Update https://gcc.gnu.org/gcc-16/changes.html for some OpenACC
features that went in; while small and some of them rather new
(OpenACC 3.4 was only released in June 2025), they all
On Tue, Jul 29, 2025 at 10:32 AM Tamar Christina
wrote:
>
> Hi Pengfei,
>
> > -Original Message-
> > From: Pengfei Li
> > Sent: Monday, July 21, 2025 12:03 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: rguent...@suse.de; s...@gentoo.org; Tamar Christina
> > ; Pengfei Li
> > Subject: [PATCH]
On 7/28/25 9:39 AM, Christoph Müllner wrote:
Function riscv_ext_is_subset () uses structured bindings to iterate over
all keys and values of an unordered map. However, this is only
available since C++17 and causes a warning like this:
warning: structured bindings only available with ‘-std=
This patch adds a new rule for distributing lowpart subregs through
ANDs, IORs, and XORs with a constant, in cases where one of the terms
then disappears. For example:
(lowart-subreg:QI (and:HI x 0x100))
simplifies to zero and
(lowart-subreg:QI (and:HI x 0xff))
simplifies to (lowart-subreg
On Tue, 29 Jul 2025, Tobias Burnus wrote:
> Thanks for proof reading and noting the missing patch …
Now for the actual patch :-)
1) Nice!
+ OpenACC 3.4: In Fortran, named constants (PARAMETER) used as
+ var in clauses are now accepted (and ignored as not being
+ required). The support
Hi!
The PR13358 r0-92909 change changed the diagnostics on long long
in C++ (either with -std=c++98 or -Wlong-long), but unlike the
C FE we unfortunately warn even in the
__extension__ long long a;
etc. cases. The C FE in that case in
disable_extension_diagnostics saves and clears not just
pedant
Ping!
On 2025-07-17 14:48, Torbjörn SVENSSON wrote:
Ok for trunk, gcc-15 and gcc-14?
--
Prior to 14-2027-g985d6480fe5, the input text had the file extensions
pruned. In 14-2027-g985d6480fe5, due to the move of the call, the
pruning is never done. This change restores the pruning of the file
ex
On Tue, 29 Jul 2025, Jakub Jelinek wrote:
> Hi!
>
> In the PR119483 r15-9003 change we've allowed musttail calls to noreturn
> functions, after all the decision not to normally tail call noreturn
> functions is not because it is not possible to tail call those, but because
> it screws up backtrac
Hi Mikail,
Yes to this third patch as well. I haven't had time to track them down but
there are other places where code has had to be inserted to prevent
non-polymorphic references in a polymorphic way. I wonder if they cannot be
unified at some time?
All three can be pushed to mainline.
Many th
Hi!
In the PR119483 r15-9003 change we've allowed musttail calls to noreturn
functions, after all the decision not to normally tail call noreturn
functions is not because it is not possible to tail call those, but because
it screws up backtraces. As the following testcase shows, we've done that
o
On Tue, Jul 29, 2025 at 08:55:05AM +0200, Richard Biener wrote:
> > The result of that is the branch "patched15". It has 47 cherry-picked
> > commits on top of gcc/releases/gcc-15. With gcc-15.1.0 as the compiler,
> > it successfully compiles on an x86_64-linux Ubuntu 22.04 LTS system
> > startin
Le 29/07/2025 à 08:53, Paul Richard Thomas a écrit :
Hi Mikail,
I apologise for the delay between reviewing this patch and the first.
Some daytime work issues came up that I couldn't ignore.
This addition is fine, does as advertised and is good for mainline.
Oops, sorry thanks for the revi
Hi!
The P2843R3 Preprocessing is never undefined paper contains comments
that various compilers handle comma operators in preprocessor expressions
incorrectly and I think they are right.
In both C and C++ the grammar uses constant-expression non-terminal
for #if/#elif and in both C and C++ that N
Hi Bob!
On 2025-07-29T09:07:24+0200, Jakub Jelinek wrote:
> On Tue, Jul 29, 2025 at 08:55:05AM +0200, Richard Biener wrote:
>> > The result of that is the branch "patched15". It has 47 cherry-picked
>> > commits on top of gcc/releases/gcc-15. With gcc-15.1.0 as the compiler,
>> > it successfull
On 28/07/2025 16:36, Sam James wrote:
Alfie Richards writes:
Hi,
Small fix to resolve an UBSAN diagnostic.
Reg tested for Aarch64
To be sure: checked with bootstrap-ubsan too? (though note that it
doesn't error out by default, so you'd need to grep the logs or set
UBSAN_OPTIONS to make it
Hi Yury,
> -Original Message-
> From: Yury Khrustalev
> Sent: Wednesday, July 23, 2025 9:45 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski ; Richard Sandiford
> ; Tamar Christina ;
> Alfie Richards ; Alice Carlotti
> ;
> Victor Do Nascimento
> Subject: [PATCH v2 2/3] testsuite: Ad
Hi Pengfei,
> -Original Message-
> From: Pengfei Li
> Sent: Monday, July 21, 2025 12:03 PM
> To: gcc-patches@gcc.gnu.org
> Cc: rguent...@suse.de; s...@gentoo.org; Tamar Christina
> ; Pengfei Li
> Subject: [PATCH] vect: Fix insufficient alignment requirement for speculative
> loads
> [PR
On Tue, 29 Jul 2025, Alfie Richards wrote:
> (Whoops, s/WIP/RFC)
>
> Hi All,
>
> This patch adds support for capping VF at runtime for VLA loops with a
> data dependency.
> On 28/07/2025 15:56, Alfie Richards wrote:
> Hi All,
>
> This patch adds support for capping VF at runtime for VLA loops w
Hi,
Thanks Tamar and Richi for the review.
> > I wonder about what the intention of this code was. It seems to me that it
> > was
> > trying to disable versioning for VLA, but then also doubling up and using
> > the
> > mode as the alignment. But the cross iteration alignment check below this
The problem here is that in tree-prof.exp does not cleanup if requiring
auto-profile
but it is not supported and the testcase uses dg-additional-sources. Currently
additional_sources
is not reset to "" and then another testcase comes along and thinks that is the
additional source
to be added.
C
I ran testsuite with --enable-symvers=gnu-versioned-namespace config and
1 test is failing because there is no dual abi in this mode and it
defaults to COW string implementation.
libstdc++: Fix test when dual abi disabled
When !_GLIBCXX_USE_DUAL_ABI the old COW std::string implementati
On Tue, Jul 29, 2025 at 5:04 PM wrote:
>
> On 2025-07-25 11:18, Uros Bizjak wrote:
> > On Thu, Jul 24, 2025 at 5:35 PM Artemiy Granat
> > wrote:
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> * g++.dg/abi/regparm1.C: Use regparm attribute only if not in
> >> 64-bit mode.
> >>
On Tue, Jul 29, 2025 at 6:58 PM Uros Bizjak wrote:
>
> On Tue, Jul 29, 2025 at 5:04 PM wrote:
> >
> > On 2025-07-25 11:18, Uros Bizjak wrote:
> > > On Thu, Jul 24, 2025 at 5:35 PM Artemiy Granat
> > > wrote:
> > >>
> > >> gcc/testsuite/ChangeLog:
> > >>
> > >> * g++.dg/abi/regparm1.C: Us
After previous patches, we should always get a VNx16BI result
for ACLE intrinsics that return svbool_t. This patch adds
an assert that checks a more general condition than that.
gcc/
* config/aarch64/aarch64-sve-builtins.cc
(function_expander::expand): Assert that the return value
Hello.
> > OK.
>
> BTW: How do you plan to go forward with these patches?
>
> If you don't have compyright assignment then we need your
> Signed-off-by: on the patches, please read "Legal Prerequisites" of
> https://gcc.gnu.org/contribute.html . Also,
Like myself, Artemiy is covered by company-
Fixes an ICE on invalid code (15/16 regression).
Bootstrapped and regression tested on x86_64.
c: Fix ICE on invalid code involving bit fields [PR121217]
Under some error condition we can end up with NULL_TREEs for
the type of bitfields, which can cause an ICE when testing for
On Tue, Jul 29, 2025 at 1:44 AM Tamar Christina wrote:
>
> Hi Yury,
>
> > -Original Message-
> > From: Yury Khrustalev
> > Sent: Wednesday, July 23, 2025 9:45 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Andrew Pinski ; Richard Sandiford
> > ; Tamar Christina ;
> > Alfie Richards ; Alice Ca
Am Dienstag, dem 29.07.2025 um 13:49 + schrieb Qing Zhao:
>
> > On Jul 28, 2025, at 17:39, Martin Uecker wrote:
> >
> > Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao:
> > >
> > > > On Jul 28, 2025, at 16:09, Martin Uecker wrote:
> > > >
> > > > >
...
> > > > > Ex 6)
> > >
On Mon, Jul 28, 2025 at 11:40 PM Jakub Jelinek wrote:
>
> On Sat, Jul 26, 2025 at 10:37:35AM -0700, H.J. Lu wrote:
> > __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.
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, July 29, 2025 02:55
> To: Robert Dubner
> Cc: Jakub Jelinek ; Richard Biener ;
> jklow...@cobolworx.com; Thomas Schwinge ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: cobol: [PATCH] Bring the COBOL front end in releases/gcc-15
>
> -Original Message-
> From: Thomas Schwinge
> Sent: Tuesday, July 29, 2025 03:46
> To: Robert Dubner
> Cc: Jakub Jelinek ; Richard Biener
> ; Richard Biener ;
> jklow...@cobolworx.com; gcc-patches@gcc.gnu.org
> Subject: Re: cobol: [PATCH] Bring the COBOL front end in releases/gcc-15
One long-standing problem with the implementation of the SVE ACLE
is that .H, .S, and .D predicate operations tend to have VNx8BI,
VNx4BI, and VNx2BI results. As with the fix for PR121118, this
representation is usually incorrect, since every bit of an svbool_t
result is significant:
https://
> On Jul 29, 2025, at 11:52, Martin Uecker wrote:
>
> Am Dienstag, dem 29.07.2025 um 13:49 + schrieb Qing Zhao:
>>
>>> On Jul 28, 2025, at 17:39, Martin Uecker wrote:
>>>
>>> Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao:
> On Jul 28, 2025, at 16:09, Martin Uecker
Hi Hans.
Thank you for the heads up.
I think it is ok to use the new default in BPF. It is extremely
unlikely it will ever impact existing current BPF programs, and when/if
it comes to that, it will help to use the best default so we can at that
point formalize the ABI.
> From: Hans-Peter Nil
> Am 29.07.2025 um 16:58 schrieb Pengfei Li :
>
> Hi,
>
> I have updated the fix and the test case as you suggested.
>
> Patch is re-tested on trunk and gcc-15. Ok for both trunk and gcc-15?
Ok, but can you put the VF check somewhere more global? It seems we never want
to do alignment ver
On Tue, 29 Jul 2025, Jakub Jelinek wrote:
> On Tue, Jul 29, 2025 at 11:02:08AM -0400, Hans-Peter Nilsson wrote:
> > > If you have a target with bogus MAX_FIXED_MODE_SIZE definition, you should
> > > just fix that.
> >
> > That macro should be avoided, for one because it's misleading
> > and ends
On Tue, Jul 29, 2025 at 11:20:25AM -0500, Robert Dubner wrote:
> I removed the pick of 0eac9cfe, and I removed the pick of ed8761241ac529,
> which had already been done by Thomas.
>
> I just applied the other 45 relevant commits, and pushed that.
Great, thanks.
git diff
r15-10108-g50c91681558e4
The patterns for the predicate forms of svtrn1/2, svuzp1/2,
and svzip1/2 are shared with aarch64_vectorize_vec_perm_const.
The .H, .S, and .D forms operate on VNx8BI, VNx4BI, and VNx2BI
respectively. Thus, for all four element widths, there is one
significant bit per element, for both the inputs a
The previous patch for PR121294 handled svtrn1/2, svuzp1/2, and svzip1/2.
This one extends it to handle svrev intrinsics, where the same kind of
wrong code can be generated.
gcc/
PR target/121294
* config/aarch64/aarch64.md (UNSPEC_REV_PRED): New unspec.
* config/aarch64/aa
On Tue, Jul 29, 2025 at 10:36 AM Tamar Christina
wrote:
>
> > -Original Message-
> > From: Pengfei Li
> > Sent: Monday, July 21, 2025 12:07 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: rguent...@suse.de; s...@gentoo.org; Tamar Christina
> > ; Pengfei Li
> > Subject: [PATCH] vect: Add missi
> -Original Message-
> From: Yury Khrustalev
> Sent: Wednesday, July 23, 2025 9:45 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski ; Richard Sandiford
> ; Tamar Christina ;
> Alfie Richards ; Alice Carlotti
> ;
> Victor Do Nascimento
> Subject: [PATCH v2 1/3] aarch64: Stop using
On Tue, 29 Jul 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Pengfei Li
> > Sent: Tuesday, July 29, 2025 10:17 AM
> > To: Richard Biener ; Tamar Christina
> >
> > Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de; s...@gentoo.org
> > Subject: Re: [PATCH] vect: Fix insufficie
Tested on x86_64-pc-linux-gnu, committed as obvious.
-- >8 --
I hadn't validated this test worked in C++14 before submitting, fixed
thusly.
PR testsuite/121285
gcc/testsuite/ChangeLog:
* g++.dg/modules/class-11_a.H: Make static_asserts valid for
C++14.
Signed-off-by: N
On Mon, Jul 28, 2025 at 10:08:34AM +0200, Rainer Orth wrote:
> Patrick Palka writes:
>
> > 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 regte
On 7/29/25 14:44, Richard Sandiford wrote:
> External email: Use caution opening links or attachments
>
>
> function_expander::get_reg_target didn't actually check for a register,
> meaning that it could return a memory target instead. That doesn't
> really matter for the current direct and indir
> On 29 Jul 2025, at 15:15, Remi Machet wrote:
>
>
> On 7/29/25 14:44, Richard Sandiford wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> function_expander::get_reg_target didn't actually check for a register,
>> meaning that it could return a memory target instea
The 8-bit and 16-bit tests in cmpbr.c assumed an inverted operand
order ("w1, w0"), but it's possible to use the uninverted operand
order too. This patch generalises the tests to support both forms.
This is a prerequisite for a later patch that adds a new
simplify-rtx.cc rule.
Tested on aarch64-
gcc.target/aarch64/saturating_arithmetic_{1,2}.c expect w0 and w1 to
be duplicated into vectors. The tests expected the duplication of w1
to happen first, but the other order would be fine too. A later
simplify-rtx.cc patch happens to change the order.
Tested on aarch64-linux-gnu. OK to install
> -Original Message-
> From: Pengfei Li
> Sent: Tuesday, July 29, 2025 12:10 PM
> To: Richard Biener
> Cc: Tamar Christina ; Richard Biener
> ; gcc-patches@gcc.gnu.org; s...@gentoo.org
> Subject: Re: [PATCH] vect: Fix insufficient alignment requirement for
> speculative
> loads [PR121190
This patch adds dispatch constraints for Neoverse V2 and illustrates the steps
necessary to enable dispatch scheduling for an AArch64 core.
The dispatch constraints are based on section 4.1 of the Neoverse V2 SWOG.
Please note that the values used here deviate slightly from the current SWOG
versio
On 29/07/2025 11:39, Richard Biener wrote:
On Tue, 29 Jul 2025, Alfie Richards wrote:
On 29/07/2025 10:13, Richard Biener wrote:
On Tue, 29 Jul 2025, Alfie Richards wrote:
(Whoops, s/WIP/RFC)
Hi All,
This patch adds support for capping VF at runtime for VLA loops with a
data dependency.
On
This patch adds dispatch scheduling for AArch64 by implementing the two target
hooks TARGET_SCHED_DISPATCH and TARGET_SCHED_DISPATCH_DO.
The motivation for this is that cores with out-of-order processing do
most of the reordering to avoid pipeline hazards on the hardware side
using large reorder b
On Tue, Jul 29, 2025 at 11:02:08AM -0400, Hans-Peter Nilsson wrote:
> > If you have a target with bogus MAX_FIXED_MODE_SIZE definition, you should
> > just fix that.
>
> That macro should be avoided, for one because it's misleading
> and ends up being used for other than target tweaking (QED).
N
> On Jul 28, 2025, at 5:54 PM, Bill Wendling wrote:
>
> On Mon, Jul 28, 2025 at 4:52 PM Yeoul Na wrote:
>>
>> Could someone working on Linux answer my earlier question? Working on a
>> compromise solution is one thing, but I’m trying to understand the situation
>> better.
>>
>>> Out of curi
Hi,
The comment in v2 is addressed. Tested again on both trunk and gcc-15.
Ok for trunk and gcc-15?
Changes in v3:
- Extract the constant VF check out.
Changes in v2:
- Remove the condition of dr_safe_speculative_read_required.
- Add a constant VF check.
Thanks,
Pengfei
-- >8 --
This patch
On Tue, 29 Jul 2025, Nathaniel Shead wrote:
> Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap+regtest
> passes?
>
> -- >8 --
>
> For the sake of determining if there are other errors in user code to
> report early, many trait functions don't return error_mark_node if not
> called i
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *str
> +(define_insn "@nds_vfwcvt_bf16"
> + [(set (match_operand:NDS_VWEXTBF 0 "register_operand"
> "=&vr")
> + (unspec_volatile:NDS_VWEXTBF
> + [(float_extend:NDS_VWEXTBF
> +(match_operand: 1 "register_operand" "
> vr"))]
> + UNSPEC_NDS_VFWCVTBF16
Am 29.07.25 um 15:56 schrieb Stefan Schulze Frielinghaus:
From: Stefan Schulze Frielinghaus
Targets hppa, m68k, pdp11, rx, sh, vax do not default to LRA. Since old
reload pass is still used, add option -mlra for those targets.
For hppa, register 0 cannot be used as a general register. Theref
> Am 29.07.2025 um 20:37 schrieb Pengfei Li :
>
> Hi,
>
> The comment in v2 is addressed. Tested again on both trunk and gcc-15.
>
> Ok for trunk and gcc-15?
>
Ok
Richard
> Changes in v3:
> - Extract the constant VF check out.
>
> Changes in v2:
> - Remove the condition of dr_safe_spe
> Am 29.07.2025 um 16:54 schrieb Pengfei Li :
>
> Hi,
>
> I have adjusted the test case as you suggested.
>
> Ok for trunk?
Ok
Thanks,
Richard
> Thanks,
> Pengfei
>
> -- >8 --
> This fixes a miscompilation issue introduced by the enablement of
> combined loop peeling and versioning. A t
> On Jul 28, 2025, at 12:48, Jakub Jelinek wrote:
>
> On Wed, Jul 23, 2025 at 05:59:22PM +, Qing Zhao wrote:
>> struct S {
>> int n;
>> int *p __attribute__((counted_by(n)));
>> } *f;
>> Int *g;
>> void setup (int **ptr, int count)
>> {
>> *ptr = __builtin_malloc (sizeof (int) * count);
>
This one is LGTM :)
On Tue, Jul 22, 2025 at 6:04 AM Jeff Law wrote:
>
>
>
> On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
> > This patch add basic support for the following XAndes ISA extensions:
> >
> > XANDESPERF
> > XANDESBFHCVT
> > XANDESVBFHCVT
> > XANDESVSINTLOAD
> > XANDESVPACKFPH
> > XANDESVDO
The failure of CI is unrelated, will commit it soon.
Pan
-Original Message-
From: Li, Pan2
Sent: Tuesday, July 29, 2025 11:23 AM
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
Jeff Law 於 2025年7月22日 週二 上午6:34寫道：
Hi Jeff,
Thanks your review.
> > +
> > +(define_insn "*nds_branch_imms7"
> > + [(set (pc)
> > + (if_then_else
> > + (match_operator 1 "equality_operator"
> > + [(match_operand:X 2 "register_operand" "r")
> > + (match_operand:X 3 "ad
r14-1902-g96c3539f2a3813 split TImode move with 2 DImode move, it's
supposed to optimize TImode in parameter/return since accoring to
psABI it's stored into 2 general registers.
But when TImode is not in parameter/return, it could create redundancy
in the PR.
The patch add a splitter to handle th
On Tue, Jul 22, 2025 at 6:40 AM Jeff Law wrote:
>
>
>
> On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
> > This extension defines instructions to perform scalar floating-point
> > conversion between the BFLOAT16 floating-point data and the IEEE-754
> > 32-bit single-precision floating-point (SP) data in
No worries, thanks!
在 2025/7/29 23:02, Kito Cheng 写道:
I thought I already merged that until today's RISC-V patchwork
meeting, committed to trunk :P
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 29, 2025 5:20 PM
> To: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra ; gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford
> Subject: [
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 29, 2025 5:20 PM
> To: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra ; gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford
> Subject: [PAT
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, July 29, 2025 1:43 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Alex Coplan ; Alice Carlotti
> ;
> pins...@gmail.com; ktkac...@nvidia.com; Richard Earnshaw
> ; Tamar Christina ;
> Wilco Dijkstra
> Subject: [PATCH] aarch64: Improve
On Tue, Jul 29, 2025 at 10:29:37PM +0200, Harald Anlauf wrote:
>
> - I am a little confused about the handling of the access specification.
> After the first "public :: g", NAG complains about the
>
> generic, public :: g ...
>
> and only allows
>
> generic :: g ...
>
> Then duplicate pub
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the floating-point forms of svcmp*.
>
> gcc/
> * config/aarch64/aarch64-sve.md (@aarch64_pred_fcm_acle)
> (*aarch64_pred_fcm_acle,
From: Pan Li
The unsigned avg ceil share the vaaddx.vx for the vx combine,
so add the test case to make sure it works well as expected.
The below test suites are passed for this patch series.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/v
I checked, and GCC 14 (and others) uses https; not sure how http snuck
in here for the GCC 15 web pages?
Pushed.
Gerald
---
htdocs/gcc-15/index.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-15/index.html b/htdocs/gcc-15/index.html
index d68da280..5670dd
> -Original Message-
> From: Richard Biener
> Sent: Monday, July 28, 2025 2:28 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
>
> Subject: [PATCH] Record get_load_store_info results from analysis
>
> The following is a prototype-quality patch to make us record
Hi Kito,
Kito Cheng 於 2025年7月30日 週三 上午9:01寫道：
>
> > +(define_insn "@nds_vfwcvt_bf16"
> > + [(set (match_operand:NDS_VWEXTBF 0 "register_operand"
> > "=&vr")
> > + (unspec_volatile:NDS_VWEXTBF
> > + [(float_extend:NDS_VWEXTBF
> > +(match_operand: 1 "reg
1 - 100 of 174 matches
Mail list logo
