On Thu, Jul 24, 2025 at 12:03:43PM +0200, Stefan Schulze Frielinghaus wrote:
> It looks like we didn't have a test so far reaching this point which
> changed with the new hard register constraint tests. Bootstrap and
> regtest are still running on x86_64. If they succeed, ok for mainline?
Meanwh
It's probably changes from the RVV cost modeling behavior, the patches
are of course not supposed to change code generation.
These tests don't use dynamic LMUL (which needs a special flag and is not
generally active) so it would be odd if they were affected by the costing
changes. In particul
On Thu, 24 Jul 2025, Robin Dapp wrote:
> > I do see regressions for zve32x-3.c et al. Those might be related to the
> > recently fixed tests regarding partial vectorization with vector(1) types
> > but I haven't checked further for now.
>
> The regressions are "scan failures". One loop is not l
libgcc/ChangeLog:
* config.host: Remove unused code. Include LoongArch-specific
tmake_files after the OS-specific ones.
---
libgcc/config.host | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/libgcc/config.host b/libgcc/config.h
This patch adds support for C23's _BitInt for LoongArch.
>From the LoongArch psABI[1]:
> _BitInt(N) objects are stored in little-endian order in memory
> and are signed by default.
>
> For N ≤ 64, a _BitInt(N) object have the same size and alignment
> of the smallest fundamental integral type tha
A _BitInt value may rely on a conversion to become properly extended.
So a conversion to _BitInt is not trivially removable even if the
types of the result and the operand have the same precision and size.
This patches fixes gcc.dg/torture/bitint-64.c at -O2 on LoongArch,
which fails because exten
A widening cast from a signed _BitInt operand to an unsigned _BitInt
type involves filling the extra limb(s) with sign extension.
On a target that wants _BitInts extended in memory, if this unsigned
type has a partial limb, the unused part of it should be zeroed.
e.g. Assuming limb_mode == E_DImod
In LoongArch psABI, large _BitInt(N) (N > 64) objects are only
extended to fill the highest 8-byte chunk that contains any used bit,
but the size of such a large _BitInt type is a multiple of their
16-byte alignment. So there may be an entire unused 8-byte
chunk that is not filled by extension, an
Changes from v3:
1. Modify BEXTC to compare in the original type of the operand
instead of the extended type of the copied object.
Due to omission of BITINT_EXTEND during expand, which forces an
actual extension from the operand to a wider type, we can no longer
rely on the value of t
In BEXTC, whether a _BitInt object is properly extended is examined
by a value comparison against a copied object in a wider _BitInt
type that utilizes all of the partial limb.
Since the (implicit) conversion to the wider type may be optimized
away and cause the result of the comparison to always
This patch also make casts of ABI-extended large/huge _BitInts
behave the same as the small/middle case, i.e. no-op for casts
to a higher precision _BitInt with the same number of limbs /
extension for casts that turns a full top limb into a partial limb.
This conveniently helps keep some code with
For targets that set the "extended" flag in TARGET_C_BITINT_TYPE_INFO,
we assume small _BitInts to be internally extended after arithmetic
operations. In this case, an extra extension during RTL expansion
can be avoided.
gcc/ChangeLog:
* expr.cc (expand_expr_real_1): Do not call
r
For targets that treat small _BitInts like the fundamental
integral types, we should allow their machine modes to be promoted
in the same way.
gcc/ChangeLog:
* explow.cc (promote_function_mode): Add a case for
small/medium _BitInts.
(promote_mode): Same.
---
gcc/explow.cc
Bootstrapped and regtested on x86_64-pc-linux-gnu. Also verified that
it fixes the regression on an mcore-elf cross. OK for trunk?
-- >8 --
The assertion failure on ASM_OUTPUT_WEAKREF targets since my r16-1738
was caused because the 'TREE_CHAIN (id)' check in assemble_name_resolve
no longer imp
On 2025/07/23 2:16, Max Filippov wrote:
Regtested for target=xtensa-linux-uclibc. Two new regressions in the
configuration
with call0 ABI:
FAIL: gcc.c-torture/execute/2603-1.c -O2 execution test
FAIL: gcc.c-torture/execute/2603-1.c -O3 -g execution test
because the load from b->d
LGTM :)
Christoph Müllner 於 2025年7月25日 週五 05:33 寫道：
> The Smrnmi extension introduces the nmret instruction to return from RNMI
> handlers. We already have basic Smrnmi support. This patch introduces
> support for the nmret instruction and the ability to set the function
> attribute `__attribu
On Thu, Jul 24, 2025 at 07:19:48PM +, Aaron Ballman wrote:
> I'll have to think about that more, but my initial reaction is: that's
> making our implementation/design problems be the user's problem. Maybe
> that's fine? But it would be kind of frustrating as a user to have
> code using `__count
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 to figure out what it means with all
> the various C++ featur
On Thu, Jul 24, 2025 at 01:16:24PM -0400, Jason Merrill wrote:
> On 7/24/25 8:40 AM, Nathaniel Shead wrote:
> > On Thu, Jul 24, 2025 at 09:02:24PM +1000, Nathaniel Shead wrote:
> > > On Tue, Jul 08, 2025 at 12:51:37PM -0400, Jason Merrill wrote:
> > > > I'm resistant to moving functions around unne
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
I noticed that C++26 trivial relocation didn't work in modules yet, and
there are a couple of other flags that seem potentially useful we
weren't streaming. This streams those flags and adds a comment to
cp-tree.h to help
Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling:
> On Thu, Jul 24, 2025 at 11:11 AM Martin Uecker wrote:
> > Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman:
> >
> >
> > constexpr size_t size = 4;
> > struct foo {
> > char (*buf)[size] __counted_by(size);
On Thu, Jul 24, 2025 at 11:11 AM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman:
> > On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote:
> > > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > > For my understanding: What is the pr
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 + schrieb Aaron Ballman:
> > > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote:
...
> >
> > TBH, I am not terrible convin
On 7/24/25 5:20 PM, Patrick Palka wrote:
On Thu, 24 Jul 2025, Jason Merrill wrote:
On 7/23/25 8:29 PM, Patrick Palka wrote:
On Wed, 23 Jul 2025, Jason Merrill wrote:
On 7/23/25 3:46 PM, Patrick Palka wrote:
As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
build_min_n
The Smrnmi extension introduces the nmret instruction to return from RNMI
handlers. We already have basic Smrnmi support. This patch introduces
support for the nmret instruction and the ability to set the function
attribute `__attribute__ ((interrupt ("rnmi")))` to let the compiler
generate RNMI
On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote:
> > > > That said, John McCall pointed out some usage patterns Apple has with
> > > > their existing feature:
> > > >
On Thu, 24 Jul 2025, Jason Merrill wrote:
> On 7/23/25 8:29 PM, Patrick Palka wrote:
> > On Wed, 23 Jul 2025, Jason Merrill wrote:
> >
> > > On 7/23/25 3:46 PM, Patrick Palka wrote:
> > > > As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
> > > > build_min_non_dep_op_overl
On 7/23/25 8:29 PM, Patrick Palka wrote:
On Wed, 23 Jul 2025, Jason Merrill wrote:
On 7/23/25 3:46 PM, Patrick Palka wrote:
As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
build_min_non_dep_op_overload how to rebuild all rewritten comparison
operators, not just != -> =
> On Jul 24, 2025, at 11:03, Martin Uecker wrote:
__counted_by(M));
```
It's kind of gross to need two attributes to do the same notional
thing, but it does solve the vast majority of the usages seen in the
wild if you're willing to accept some awkwardness around things
Am Donnerstag, dem 24.07.2025 um 19:19 + schrieb Aaron Ballman:
> On Thu, Jul 24, 2025 at 6:11 PM Martin Uecker wrote:
> >
> > Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman:
> > > On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote:
> > > >
> > > > Am Donnerstag, dem 24
On 7/24/25 21:35, Thomas Koenig wrote:
Am 23.07.25 um 21:47 schrieb Toon Moene:
Today I used Thomas's "locks" example code from the same e-mail
message (showing the full output):
Actually, I think that example is flawed, it lacks synchronization.
Sorry for that.
Good - hope it's not too h
On 7/24/25 2:43 PM, Patrick Palka wrote:
On Thu, 24 Jul 2025, Jason Merrill wrote:
The lambda conversion was ICEing for two C++23 features, static op() and
explicit object parameters. The issue with the former seems like a more
general issue: tsubst_function_decl recursing to substitute the pa
Am 23.07.25 um 21:47 schrieb Toon Moene:
Today I used Thomas's "locks" example code from the same e-mail message
(showing the full output):
Actually, I think that example is flawed, it lacks synchronization.
Sorry for that.
Best regards
Thomas
On x86-64, __tls_get_addr is a normal function which doesn't preserve
vector registers. On i386, ___tls_get_addr preserve vector registers
only with the commit:
848f0e46f0 i386: Update ___tls_get_addr to preserve vector registers
which fixed:
https://sourceware.org/bugzilla/show_bug.cgi?id=3299
On Thu, Jul 24, 2025 at 6:11 PM Martin Uecker wrote:
>
> Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman:
> > On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote:
> > >
> > > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > > > On Wed, Jul 23, 2025 at 8:3
Andrew Stubbs wrote:
On 24/07/2025 16:49, Tobias Burnus wrote:
Andrew Stubbs wrote:
On 24/07/2025 14:25, Tobias Burnus wrote:
+/* Device requires CDNA1-style manually inserted wait states for
AVGPRs. */
+#define TARGET_AVGPR_CDNA3_NOPS TARGET_CDNA3
This is not for CDNA1, and not for AVGPRS.
On Thu, 24 Jul 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> The lambda conversion was ICEing for two C++23 features, static op() and
> explicit object parameters. The issue with the former seems like a more
> general issue: tsubst_function_decl re
Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman:
> On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote:
> >
> > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote:
> > >
> >
...
> > >
> > > Personall
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The lambda conversion was ICEing for two C++23 features, static op() and
explicit object parameters. The issue with the former seems like a more
general issue: tsubst_function_decl recursing to substitute the parameters
was affected by cp_u
Subject: [PATCH] cobol: Honor the "-static" command-line option.
[PR119231]
gcc/cobol/ChangeLog:
PR cobol/119231
* gcobolspec.cc: (lang_specific_driver): Pass OPT_static through.
Handle -static and -static-libgcobol properly.
gcc/testsuite/ChangeLog:
* cobol.dg/g
On 7/24/25 8:40 AM, Nathaniel Shead wrote:
On Thu, Jul 24, 2025 at 09:02:24PM +1000, Nathaniel Shead wrote:
On Tue, Jul 08, 2025 at 12:51:37PM -0400, Jason Merrill wrote:
I'm resistant to moving functions around unnecessarily, as it makes git
change tracking a lot harder. Especially when it me
On Wed, 23 Jul 2025, Patrick Palka wrote:
> On Wed, 23 Jul 2025, Jason Merrill wrote:
>
> > On 7/23/25 3:46 PM, Patrick Palka wrote:
> > > As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
> > > build_min_non_dep_op_overload how to rebuild all rewritten comparison
> > > ope
> On 24 Jul 2025, at 17:46, Jason Merrill wrote:
>
> On 7/24/25 12:39 PM, Iain Sandoe wrote:
>>> On 24 Jul 2025, at 17:31, Jason Merrill wrote:
>>>
>>> On 7/24/25 10:24 AM, Iain Sandoe wrote:
>>> We should check (gcc_checking_assert?) that NRVO works in the case
>>> where we expect
On 7/24/25 12:39 PM, Iain Sandoe wrote:
On 24 Jul 2025, at 17:31, Jason Merrill wrote:
On 7/24/25 10:24 AM, Iain Sandoe wrote:
We should check (gcc_checking_assert?) that NRVO works in the case where we
expect it to, rather than let NRVO failures show up as wrong-code.
This seems a simple
On 24/07/2025 16:49, Tobias Burnus wrote:
Andrew Stubbs wrote:
On 24/07/2025 14:25, Tobias Burnus wrote:
+/* Device requires CDNA1-style manually inserted wait states for
AVGPRs. */
+#define TARGET_AVGPR_CDNA3_NOPS TARGET_CDNA3
This is not for CDNA1, and not for AVGPRS.
I have deleted it
> On 24 Jul 2025, at 17:31, Jason Merrill wrote:
>
> On 7/24/25 10:24 AM, Iain Sandoe wrote:
> We should check (gcc_checking_assert?) that NRVO works in the case where
> we expect it to, rather than let NRVO failures show up as wrong-code.
This seems a simple request - but it see
As reported in https://gcc.gnu.org/pipermail/gcc/2025-July/246417.html,
This fixes the minor typo under the #ifdef documentation about adding
MACRO after the #endif and the MACRO matching of the #ifdef. It had `#ifndef`
in it, rather than `#ifdef`.
Pushed as obvious.
gcc/ChangeLog:
* doc
On 7/24/25 10:24 AM, Iain Sandoe wrote:
We should check (gcc_checking_assert?) that NRVO works in the case where we
expect it to, rather than let NRVO failures show up as wrong-code.
This seems a simple request - but it seems quite involved to implement;
the conditions that have to be met are n
On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote:
>
> Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote:
> > >
> ...
>
> >
> > > > That said, John McCall pointed out some usage patterns Apple has with
> > > > their exist
Andrew Stubbs wrote:
On 24/07/2025 14:25, Tobias Burnus wrote:
+/* Device requires CDNA1-style manually inserted wait states for
AVGPRs. */
+#define TARGET_AVGPR_CDNA3_NOPS TARGET_CDNA3
This is not for CDNA1, and not for AVGPRS.
I have deleted it and use now TARGET_CDNA3 directly.
+
I do see regressions for zve32x-3.c et al. Those might be related to the
recently fixed tests regarding partial vectorization with vector(1) types
but I haven't checked further for now.
The regressions are "scan failures". One loop is not loop vectorized any more
but SLP vectorized and the f
gcc/ChangeLog:
* config/i386/i386-options.cc (ix86_handle_cconv_attribute):
Handle simultaneous use of regparm and thiscall attributes in
case when regparm is set before thiscall.
gcc/testsuite/ChangeLog:
* gcc.target/i386/attributes-error.c: Add more attributes
The regparm attribute does not affect code generation on x86-64 target.
Despite this, regparm was accepted silently, unlike other calling
convention attributes handled in the ix86_handle_cconv_attribute
function.
Due to lack of diagnostics, Linux kernel attempted to specify regparm(0)
on vmread_er
gcc/ChangeLog:
* config/i386/i386-options.cc (ix86_handle_cconv_attribute):
Fix comments which state that combination of stdcall and fastcall
attributes is valid but redundant.
---
gcc/config/i386/i386-options.cc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
gcc/ChangeLog:
* config/i386/i386-options.cc (ix86_handle_cconv_attribute):
Fix typo.
---
gcc/config/i386/i386-options.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index e7b200cd4f1..f6cca6
The following removes the non-SLP gimple **vec_stmt argument from
the vectorizable_* functions API. Checks on it can be replaced
by an inverted check on the passed cost_vec vector pointer.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vectorizer.h (vectorizable_induct
Hello,
Changes from V1:
Corrected Commit Message.
Configure script previously accepted unsupported --with-long-double-64
option without any warning, leading to confusion. This option was
mistakenly documented in install.texi but never handled by configure
script, resulting in it bein
Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote:
> >
...
>
> > > That said, John McCall pointed out some usage patterns Apple has with
> > > their existing feature:
> > >
> > > * 655 simple references to variables or str
>>>We should check (gcc_checking_assert?) that NRVO works in the case where we
>>>expect it to, rather than let NRVO failures show up as wrong-code.
>>This seems a simple request - but it seems quite involved to implement;
>>the conditions that have to be met are numerous - I've made an attempt (t
On Wed, Jul 23, 2025 at 7:40 PM Kees Cook wrote:
>
> On Wed, Jul 23, 2025 at 11:53:40AM +, Aaron Ballman wrote:
> > That said, John McCall pointed out some usage patterns Apple has with
> > their existing feature:
> >
> > * 655 simple references to variables or struct members: __counted_by(len
On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote:
>
> Am Mittwoch, dem 23.07.2025 um 11:53 + schrieb Aaron Ballman:
> > On Wed, Jul 23, 2025 at 5:47 AM Martin Uecker wrote:
> > >
> >
> > This is a personal stance of mine, not a Clang community response.
> >
> >
> > > But this requires true
On 7/24/25 6:59 AM, Iain Sandoe wrote:
return machinery to return the g_r_o_o_a_f.
I think it should be simpler/cleaner to move the grooaf case to the 'else'
rather than the 'then', to accommodate the NRVO limitation described in
check_return_expr:
Done.
same type.
We should check
On 24/07/2025 14:25, Tobias Burnus wrote:
Hello Andrew, hello world,
some instructions take a bit longer but permit that the next
instruction is processed while finishing the work. That works
well - and speeds up the calculation - unless the next instruction
relies on those being available.
Whic
Ping.
The patch has been committed to trunk 2 months ago.
Okay for committing to GCC15 now?
thanks.
Qing
> On Jul 17, 2025, at 17:26, Qing Zhao wrote:
>
> There is only one last_field for a structure type, but there might
> be multiple last_fields for a union type, therefore we should ORed
>
Hello Andrew, hello world,
some instructions take a bit longer but permit that the next
instruction is processed while finishing the work. That works
well - and speeds up the calculation - unless the next instruction
relies on those being available.
Which combinations instructions are affected ar
Ping.
The patch has been committed to trunk 2 months ago.
Okay for committing to GCC15 now?
thanks.
Qing
> On Jul 17, 2025, at 17:26, Qing Zhao wrote:
>
> The root cause of the bug is: the TYPE_INCLUDES_FLEXARRAY marking of the
> structure type is not copied to its aliased type.
> The fix i
This replaces most test_constexpr invocations with direct calls to
test_ranges(), which is also used for runtime tests.
SimpleAllocator was made constexpr to simplify this refactoring. Other
test allocators, like uneq_allocator (used in from_range constructor
tests), were not updated.
libstdc++-v
---
gcc/tree-vect-stmts.cc | 44 +++---
1 file changed, 7 insertions(+), 37 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 10d05a87830..b38d78500aa 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -12564,7 +12
This removes the non-SLP path from vectorizable_early_exit.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu, will
squash and push when succeeded.
* tree-vect-stmts.cc (vectorizable_early_exit): Remove non-SLP
path.
---
gcc/tree-vect-stmts.cc | 51 +++
---
gcc/tree-vect-stmts.cc | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 203c21b460a..10d05a87830 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -12564,7 +12564,7 @@ vectorizable_early_e
This removes the non-SLP path from vectorizable_simd_clone_call and
the then unused simd_clone_info from the stmt_vec_info structure.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Will squash and push if that succeeds.
* tree-vectorizer.h (_stmt_vec_info::simd_clone_info
On 7/24/25 08:19, Spencer Abson wrote:
> External email: Use caution opening links or attachments
>
>
> This patch extends the expander for conditional smax, smin, add, sub, mul,
> min, max, and div to support partial SVE FP modes.
>
> If exceptions from undefined vector elements must be suppresse
---
gcc/tree-vect-stmts.cc | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index c6fdbe13a48..fa86aecd9bc 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -4017,7 +4017,7 @@ ve
On Wed, 23 Jul 2025, Tomasz Kamiński wrote:
> This replaces most test_constexpr invocations with direct calls to
> test_ranges(), which is also used for runtime tests.
>
> SimpleAllocator was made constexpr to simplify this refactoring. Other
> test allocators, like uneq_allocator (used in from_r
On Tue, Jul 22, 2025 at 11:46 AM Robin Dapp wrote:
>
> Hi,
>
> This patch prepares the dynamic LMUL vector costing to use the coming
> SLP_TREE_TYPE instead of the (to-be-removed) STMT_VINFO_TYPE.
>
> Even though the whole approach should be reviewed and adjusted at some
> point, the patch chooses
---
gcc/tree-vect-stmts.cc | 115 ++---
1 file changed, 26 insertions(+), 89 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index fa86aecd9bc..3f9edb79479 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -3954,7 +39
On Thu, 24 Jul 2025, Tomasz Kamiński wrote:
> Removed the wrong_stuff() function, which was effectively empty for
> actual test runs. Replaced the manual failure counter with the VERIFY
> macro to simplify identifying failures.
LGTM
>
> PR libstdc++/104874
>
> libstdc++-v3/ChangeLog:
>
Ping
(Libatomic autoinclude patch that this patch series depends on has been
re-spinned, so bringing this patch series back to attention).
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688838.html
On 11/14/24 13:55, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
Not sure who to C
Stefan kindly ran a regtest on s390 which looked OK as well.
I re-tested everything one more time and will commit soon. The patches were
bootstrapped individually on x86 (and built on riscv) so I hope it's safe to
not squash them.
Thanks for the guidance on that patch/series.
--
Regards
Rob
Ping
(Libatomic autoinclude patch that this patch series depends on has been
re-spinned, so bringing this patch series back to attention).
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688838.html
On 11/14/24 13:55, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
Use wrapper in bu
Ping
(Libatomic autoinclude patch that this patch series depends on has been
re-spinned, so bringing this patch series back to attention).
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688838.html
On 11/14/24 13:55, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
N.b. we match whi
Ping
(Libatomic autoinclude patch that this patch series depends on has been
re-spinned, so bringing this patch series back to attention).
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688838.html
On 11/14/24 13:55, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
Not sure who to C
---
gcc/tree-vect-stmts.cc | 44 ++
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index a1847dc3f0d..949bee3b453 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11812,7 +1
This removes the non-SLP path from vectorizable_comparison.
Bootstrapped and tested on x86_64-unknown-linux-gnu, squashed and pushed.
* tree-vect-stmts.cc (vectorizable_comparison_1): Remove
non-SLP path.
(vectorizable_comparison): Likewise.
---
gcc/tree-vect-stmts.cc | 2
---
gcc/tree-vect-stmts.cc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index dee6185106f..616b596b1c3 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -12327,7 +12327,7 @@ vectorizable_comparison_1 (
Ping
(Libatomic autoinclude patch that this patch series depends on has been
re-spinned, so bringing this patch series back to attention).
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688838.html
On 11/14/24 13:55, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
N.b. including te
The following removes the non-SLP paths from vectorizable_condition.
* tree-vect-stmts.cc (vectorizable_condition): Remove
non-SLP paths.
---
gcc/tree-vect-stmts.cc | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/gcc/tree-vect-stmts.c
This removes the non-SLP paths from vectorizable_shift.
* tree-vect-stmts.cc (vectorizable_shift): Remove non-SLP paths.
---
gcc/tree-vect-stmts.cc | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index e98
---
gcc/tree-vect-stmts.cc | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index ca941aa5bc9..90a90ebe6de 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -7788,7 +7788,7 @@ vectorizable_scan_
This removes the non-SLP paths from vectorizable_scan_store.
* tree-vect-stmts.cc (vectorizable_scan_store): Remove
non-SLP path and unused parameters.
(vectorizable_store): Adjust.
---
gcc/tree-vect-stmts.cc | 38 ++
1 file changed, 6 i
---
gcc/tree-vect-stmts.cc | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 9bed36283cf..a1847dc3f0d 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11812,7 +11812,7 @@ vectorizable_condition
This removes the non-SLP paths from vectorizable_assignment
* tree-vect-stmts.cc (vectorizable_assignment): Remove
non-SLP paths.
---
gcc/tree-vect-stmts.cc | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/g
---
gcc/tree-vect-stmts.cc | 111 -
1 file changed, 42 insertions(+), 69 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index aa2b7fa7c40..e98b02c3d39 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -5997,7 +59
---
gcc/tree-vect-stmts.cc | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index dcee631fd82..aa2b7fa7c40 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -6094,7 +6094,7 @@ vectorizab
---
gcc/tree-vect-stmts.cc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index ba0b94c93da..8f9aad9d7f1 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -5857,7 +5857,7 @@ vectorizable_assignment (vec_
Ping
(Libatomic autoinclude patch that this patch series depends on has been
re-spinned, so bringing this patch series back to attention).
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688838.html
On 11/14/24 13:55, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
Cc'ing in build m
On Thu, Jul 24, 2025 at 09:02:24PM +1000, Nathaniel Shead wrote:
> On Tue, Jul 08, 2025 at 12:51:37PM -0400, Jason Merrill wrote:
> > I'm resistant to moving functions around unnecessarily, as it makes git
> > change tracking a lot harder. Especially when it means moving a function to
> > a file t
On Thu, Jul 24, 2025 at 2:20 PM Alfie Richards wrote:
>
> Hi,
>
> This patch comes from me getting confused about gimple dumps from vect.
> Specifically, while seemingly not causing any issues I found the conversion of
> the IV step from an integral step, to a pointer value, and then to sizetype
>
This patch extends the expander for conditional smax, smin, add, sub, mul,
min, max, and div to support partial SVE FP modes.
If exceptions from undefined vector elements must be suppressed, this
expansion converts the container-level predicate to an element-level one, and
ensures that these eleme
Hi all,
Here is v2 of patch 11/14 from the unpacked FP series [1]. Apologies for
the delay in posting.
Changes since V1:
* Applied Richard's suggestions RE comments, and the code change
for aarch64_sve_emit_masked_fp_pred.
* The tests now use -moverride=sve_width=2048, an
1 - 100 of 124 matches
Mail list logo
