I originally made a more complicated patch (V5) on September 22nd, 2025 that
tried to do infrastructure cleanup as well as adding -mcpu=future. This patch
is a more limited patch in that it just adds the -mcpu=future patch, and it does
not do the other infrastructure work.
This patch just adds su
> On 3 Nov 2025, at 9:35 am, Kugan Vivekanandarajah
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> I've implemented hierarchical discriminators for AutoFDO
> This helps AutoFDO profile accuracy by:
> - Loop iterations are now uniquely identifiable in pro
On Thu, Nov 6, 2025 at 6:22 PM Andrew MacLeod wrote:
>
> I can add a check in the inferred range manager for atomic loads to
> resolve this PR.
> The IL sequence tends to look like:
>
> _1 = &this_2(D)->b;
> __atomic_load_8 (_1, 0);
>
> Just want to make sure I get this right since memor
Hi,
I have incorporated the changes suggested in version 1 and added 2 tests for
vec_set and vec_extract, I am not sure if a test for vec_extract is needed.
Bootstrapped and regtested on powerpc64le and x86 with no regressions.
Ok for trunk? Should this go in 13/14/15 as well?
Change from v1:
- A
I can add a check in the inferred range manager for atomic loads to
resolve this PR.
The IL sequence tends to look like:
_1 = &this_2(D)->b;
__atomic_load_8 (_1, 0);
Just want to make sure I get this right since memory operations are not
my strong suit.
The first argument to the atom
Pushed to r16-5073.
在 2025/11/5 上午9:50, Lulu Cheng 写道:
When the mode of the destination operand selected by the condition
is SImode, explicit sign extension is applied to both selected
source operands, and the destination operand is marked as
sign-extended.
This method can eliminate some of the
Pushed to r16-5072.
在 2025/11/5 上午9:49, Lulu Cheng 写道:
The original implementation of the function loongarch_extend_comparands
only prevented op1 from being loaded into the register when op1 was
const0_rtx. It has now been modified so that op1 is not loaded into
the register as long as op1 is a
Pushed to r16-5071.
在 2025/11/5 上午9:50, Lulu Cheng 写道:
This optimization can eliminate redundant immediate load instructions
during CSE optimization.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_legitimize_move): Optimize.
gcc/testsuite/ChangeLog:
* gcc.t
When optimize_unreachable was moved from fab to forwprop, I missed that due to
the integrated copy prop, we might end up with an already true branch leading
to a __builtin_unreachable block. optimize_unreachable would switch around
the if and things go down hill from there since the other edge was
On Thu, Nov 6, 2025 at 4:16 PM Andrew Pinski
wrote:
>
> When optimize_unreachable was moved from fab to forwprop, I missed that due to
> the integrated copy prop, we might end up with an already true branch leading
> to a __builtin_unreachable block. optimize_unreachable would switch around
> the
When optimize_unreachable was moved from fab to forwprop, I missed that due to
the integrated copy prop, we might end up with an already true branch leading
to a __builtin_unreachable block. optimize_unreachable would switch around
the if and things go down hill from there since the other edge was
On Thu, Nov 6, 2025 at 8:56 AM Karl Meakin via Sourceware Forge
wrote:
>
>
> From: Karl Meakin
>
> The bodies of `movcc` and `movcc` are identical, so merge
> them by using a new mode iterator that combines `ALLI` and `GPF`.
This patch is a good improvement, ok.
Note a related issue is fcsel is
Andrew Stubbs wrote:
This adds support for using Cuda Managed Memory with omp_alloc. AMD support
will be added in a future patch.
There is one new predefined allocator, "ompx_gnu_managed_mem_alloc", plus a
corresponding memory space, which can be used to allocate memory in the
"managed" space.
The BPF backend inline memmove expansion was broken for certain
constructs. This patch addresses the two underlying issues:
1. Off-by-one in the "backwards" unrolled move loop offset.
2. Poor use of temporary register for the generated move loop, which
could result in some of the loads performi
While working on other things, I noticed that the documentation for
the -mbranch-protection= option was pretty garbled on both aarch64 and
arm targets, with incorrect markup, too much syntax crammed into the
option summary, and confusion about what the values "+leaf" modifier
can apply to. I rewro
On 11/4/25 4:47 PM, Oleg Endo wrote:
On Sat, 2025-11-01 at 10:34 -0600, Jeff Law wrote:
This is Shreya's work except for the SH testcase which I added after
realizing her work would also fix the testcases for that port. I
bootstrapped and regression tested this on sh4-linux-gnu, x86_64 &
r
On Thu, 6 Nov 2025, Marc Poulhiès wrote:
> This adds the news part for the FOSDEM call for participation.
Great idea, thank you!
> + href="https://inbox.sourceware.org/gcc/[email protected]/";>GCC
> developer room at FOSDEM 2026: Call for Participation open
I think we can s
On 11/6/25 08:06, Alfie Richards wrote:
Hi All,
Updated this patch to use r15 for argument passing (except on windows targets)
which I missed.
Updated the wording of the documentation and a comment slightly as it had caused
some confusion.
Reg tested on aarch64-linux-gnu.
Okay for master?
T
Hi Joseph,
A gentle ping, now that Sandra has merged patch 1/1.
Have a lovely night!
Alex
On Tue, Oct 14, 2025 at 04:41:32PM +0200, Alejandro Colomar wrote:
> Store the 'rid' value in a local variable, and pass it to functions that
> handle various keywords. This simplifies the code, and remov
On 11/5/25 07:03, Christophe Lyon via Sourceware Forge wrote:
+GCC only supports the 'alternative' format on implementations that
+support it in hardware; there is no support for conversions to and
+from this format using library functions. Furthermore, you cannot
+link together code compiled w
On Thu, Nov 6, 2025 at 1:29 PM Jerry D via Gcc-bugs
wrote:
>
> I do not know what to do with this:
>
> Help requested.
It looks like libgfortran/Makefile.in was not regenerated correctly
after the libgfortran/Makefile.am changes were applied.
Or regenerated with the wrong version of automake.
Th
On 11/3/25 04:11, Alfie Richards wrote:
Hi All,
Minor update addressing Gerald Pfeifers feedback.
This is OK. We've still got problems with "ARM" vs "Arm" naming
throughout the manual, but I don't think that needs to hold up other
improvements to the documentation. (But, yeesh. What were
Instead of mentioning novector twice once under the C headline and another
time under the C++ headline, just mention it once under the C family section.
Signed-off-by: Andrew Pinski
---
htdocs/gcc-14/changes.html | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/htdocs
On 11/3/25 02:43, Alejandro Colomar wrote:
Hi Sandra, Joseph,
On Sun, Nov 02, 2025 at 08:47:15PM -0700, Sandra Loosemore wrote:
On 11/2/25 14:29, Alejandro Colomar wrote:
[CC += Sandra]
Gentle ping. :)
On Tue, Oct 14, 2025 at 04:26:35PM +, Joseph Myers wrote:
On Tue, 14 Oct 2025, Aleja
Hi Harald!
On Thu, 6 Nov 2025 21:15:50 +0100
Harald Anlauf wrote:
> Hi Christopher!
>
> Am 05.11.25 um 22:30 schrieb Christopher Albert:
> > On Wed, 5 Nov 2025 13:12:04 -0800
> > Steve Kargl wrote:
> >
> >> On Sun, Nov 02, 2025 at 02:20:59PM +0100, Christopher Albert wrote:
> >>> Rebased agai
I just updated the PR to remove the multithreaded_swap.cc test that I
had copied from the vector tests but had no meaning for the inplace_vector.
François
On 11/3/25 22:17, François Dumont wrote:
Hi
Here is v2 with swap defined as inline friend.
I also did some simplifications like reducing
On Thu, Nov 6, 2025 at 7:58 AM Marc Poulhiès wrote:
>
> ---
> htdocs/index.html | 4
> 1 file changed, 4 insertions(+)
>
> Hello,
>
> This adds the news part for the FOSDEM call for participation.
>
> Ok to push?
>
> I've applied the w3 validator to index.html and see a bunch of errors with
Compilation of the patch just finished here.
I now get an ICE (regression) on the following code:
program minimal_bug
implicit none
type :: nested_t
type(nested_t), allocatable :: children(:)
type(nested_t), allocatable :: relatives(:)
end type nested_t
type(nested_t) :: a
On Thu, Nov 6, 2025 at 8:43 AM Karl Meakin via Sourceware Forge
wrote:
>
>
> From: Karl Meakin
>
> The `movcc` expander was not used anywhere. Delete
> it.
I noticed this was not used anywhere either (when was working on
adding TImode comparison) and submitted a patch to remove this as I
didn't
Hi Christopher!
Am 05.11.25 um 22:30 schrieb Christopher Albert:
On Wed, 5 Nov 2025 13:12:04 -0800
Steve Kargl wrote:
On Sun, Nov 02, 2025 at 02:20:59PM +0100, Christopher Albert wrote:
Rebased again on trunk with small corrections, correct text format
directly pasted in the e-mail and witho
OK thanks
On Thu, 6 Nov 2025 at 16:07, Tomasz Kamiński wrote:
>
> PR libstdc++/122425
>
> libstdc++-v3/ChangeLog:
>
> * include/std/optional
> (ranges::enable_borrowed_range>): Define.
> * testsuite/20_util/optional/range.cc: Update tests.
> ---
> libstdc++-v3/inc
This happens in the name of a procedure call, again when there is an implicit
dereference in this name, and the fix to apply to Find_Selected_Component is
again straightforward:
diff --git a/gcc/ada/sem_ch8.adb b/gcc/ada/sem_ch8.adb
index 18418e92a1e..0fd7bd26c96 100644
--- a/gcc/ada/sem_ch8.adb
On 06/11/2025 19:30, Christopher Bazley wrote:
On 05/11/2025 12:25, Richard Biener wrote:
On Tue, 4 Nov 2025, Christopher Bazley wrote:
On 28/10/2025 13:29, Richard Biener wrote:
+/* Materialize mask number INDEX for a group of scalar stmts in
SLP_NODE
that
+ operate on NVECTORS vectors
Jerry,
can please wait a little?
I have a few comments coming up.
Best,
Harald
Am 06.11.25 um 20:09 schrieb Jerry D:
On 11/6/25 10:03 AM, Steve Kargl wrote:
On Thu, Nov 06, 2025 at 08:47:45AM -0800, Jerry D wrote:
On 11/5/25 3:48 PM, Steve Kargl wrote:
On Wed, Nov 05, 2025 at 11:32:39PM +0
On 05/11/2025 12:25, Richard Biener wrote:
On Tue, 4 Nov 2025, Christopher Bazley wrote:
On 28/10/2025 13:29, Richard Biener wrote:
+/* Materialize mask number INDEX for a group of scalar stmts in SLP_NODE
that
+ operate on NVECTORS vectors of type VECTYPE, where 0 <= INDEX <
NVECTORS.
+
This patch from Joseph Koshy uses the correct names in the #undef
lines for the ELFMAGn macros. Bootstrapped and ran libbacktrace tests
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
* elf.c (ELFMAGn): In #undef rename from ELF_MAGn.
86db2360bfb3d9bc12db803124b33a86b974f023
diff -
It is possible to declare a subprogram renaming whose name is a primitive
subprogram in object notation; in this case, the name is unconditionally
evaluated in the front-end (unlike for objects) so that, if an ad-hoc body
needs to be built for the renaming later, the name is not reevaluated for
On 11/6/25 10:03 AM, Steve Kargl wrote:
On Thu, Nov 06, 2025 at 08:47:45AM -0800, Jerry D wrote:
On 11/5/25 3:48 PM, Steve Kargl wrote:
On Wed, Nov 05, 2025 at 11:32:39PM +0100, Christopher Albert wrote:
On Wed, 5 Nov 2025 13:36:59 -0800
Steve Kargl wrote:
On Wed, Nov 05, 2025 at 10:30:57PM
On 11/6/25 10:13 AM, Palmer Dabbelt wrote:
On Wed, 05 Nov 2025 18:31:36 PST (-0800), Jeff Law wrote:
Let's consider this code fragment (from xalan):
[snip]
Then we realized we really should just ignore the (set (reg) (const_int
0)) in the if-converted sequence. We're going to be able to
On Thu, Nov 6, 2025 at 8:53 AM Karl Meakin via Sourceware Forge
wrote:
>
>
> From: Karl Meakin
>
> Apply the same fix from bc11cbff9e648fdda2798bfa2d7151d5cd164b87
> ("aarch64: Fix condition accepted by movcc") to `MOVcc`.
> Fixes ICEs when compiling code such as `cmpbr-4.c` with `+cmpbr`.
>
> gc
On Thu, Nov 06, 2025 at 08:47:45AM -0800, Jerry D wrote:
> On 11/5/25 3:48 PM, Steve Kargl wrote:
> > On Wed, Nov 05, 2025 at 11:32:39PM +0100, Christopher Albert wrote:
> > > On Wed, 5 Nov 2025 13:36:59 -0800
> > > Steve Kargl wrote:
> > >
> > > > On Wed, Nov 05, 2025 at 10:30:57PM +0100, Christ
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122078
GCC defines the __atomic_test_and_set builtin in gcc/sync-builtins.def
On architectures without atomic operations this builtin gets implemented
as a call to a function with the same name.
Libatomic does not provide a symbol named
On Wed, 05 Nov 2025 18:31:36 PST (-0800), Jeff Law wrote:
Let's consider this code fragment (from xalan):
[snip]
Then we realized we really should just ignore the (set (reg) (const_int
0)) in the if-converted sequence. We're going to be able to propagate
that away in nearly every case since
Georg-Johann Lay writes:
> On functional safety devices (AVR-SD), each executed instruction must
> be followed by a valid opcode. This is because instruction fetch and
> decode for the next instruction runs while the 2-stage pipeline is
> executing the current instruction.
>
> There is only one
From: Karl Meakin
The bodies of `movcc` and `movcc` are identical, so merge
them by using a new mode iterator that combines `ALLI` and `GPF`.
gcc/ChangeLog:
* config/aarch64/aarch64.md (movcc): Merge with ...
(movcc): ... this.
* config/aarch64/iterators.md(ALLI_GPF): N
From: Karl Meakin
Apply the same fix from bc11cbff9e648fdda2798bfa2d7151d5cd164b87
("aarch64: Fix condition accepted by movcc") to `MOVcc`.
Fixes ICEs when compiling code such as `cmpbr-4.c` with `+cmpbr`.
gcc/ChangeLog:
* config/aarch64/aarch64.md(movcc): Accept MODE_CC
condit
So pre-commit CI flagged an issue with the initial version of this
patch. In particular the cmp-mem-const-{1,2} tests are failing.
I didn't see that in my internal testing, but that well could be an
artifact of having multiple patches touching in the same broad space
that the tester is eval
From: Karl Meakin
The checks for `code == UNEQ || code == LTGT` are unecessary, because
they are already excluded by `aarch64_comparison_operator`
gcc/ChangeLog:
* config/aarch64/aarch64.md (mov): Delete
redundant check.
(movcc): Likewise.
(cc): Likewise.
---
g
Hi gcc-patches mailing list,
Karl Meakin has requested that the following forgejo
pull request
be published on the mailing list.
Created on: 2025-09-30 16:40:31+00:00
Latest update: 2025-11-06 16:41:31+00:00
Changes: 4 changed files, 46 additions, 59 deletions
Head revision: karmea01/gcc-TEST re
On 11/5/25 3:48 PM, Steve Kargl wrote:
On Wed, Nov 05, 2025 at 11:32:39PM +0100, Christopher Albert wrote:
On Wed, 5 Nov 2025 13:36:59 -0800
Steve Kargl wrote:
On Wed, Nov 05, 2025 at 10:30:57PM +0100, Christopher Albert wrote:
Sorry, some trouble with email client. I try claws-mail now and
From: Karl Meakin
Deduplicate the checks against `ccmode` by extracting to a new
predicate.
gcc/ChangeLog:
* config/aarch64/aarch64.md(movcc): Use new predicate.
(movcc): Likewise.
(cc): Likewise.
* config/aarch64/predicates.md (aarch64_comparison_operator_cc):
From: Karl Meakin
The `movcc` expander was not used anywhere. Delete
it.
gcc/ChangeLog:
* config/aarch64/aarch64.md (movcc): Delete.
---
gcc/config/aarch64/aarch64.md | 19 ---
1 file changed, 19 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aar
From: Andrew Stubbs
This adds support for using Cuda Managed Memory with omp_alloc. AMD support
will be added in a future patch.
There is one new predefined allocator, "ompx_gnu_managed_mem_alloc", plus a
corresponding memory space, which can be used to allocate memory in the
"managed" space.
We are currently overly restrictive with rejecting conversions from
bit-precision entities to mode precision ones. Similar to RTL expansion
we can focus on non-bit operations producing bit-precision results
which we currently do not properly handle by masking. Such checks
should be already presen
---
htdocs/index.html | 4
1 file changed, 4 insertions(+)
Hello,
This adds the news part for the FOSDEM call for participation.
Ok to push?
I've applied the w3 validator to index.html and see a bunch of errors with the
file, but not when pointing it to gcc.gnu.org.
I'm probably not usin
On Wed, 5 Nov 2025, Andrew Pinski wrote:
> On Wed, Nov 5, 2025 at 6:54 AM Andrew MacLeod wrote:
> >
> > On 11/5/25 04:55, Richard Biener wrote:
> > > This clarifies the constraints of the immediate use iterators,
> > > documenting how exactly stmts and their immediate uses might be
> > > altered
On Thu, Nov 06, 2025 at 10:49:01PM +0800, Kito Cheng wrote:
> This patch implements _BitInt support for RISC-V target by defining the
> type layout and ABI requirements. The limb mode selection is based on
> the bit width, using appropriate integer modes from QImode to TImode.
> The implementation
From: Christophe Lyon
This effective-target does not need to check for arm32, but needs to
force -march=armv8-a, otherwise -mfpu=fp-armv8 has no useful meaning.
While fixing that, introduce
check_effective_target_arm_v8_vfp_ok_nocache, so that arm_v8_vfp_ok
behaves like arm_v8_neon_ok and many
Hi,
The gather/scatter relaxation patches introduced a bug with
vect_use_strided_gather_scatters_p. I didn't want to pass
supported_offset_vectype and supported scale all the way from
vect_truncate_gather_scatter_offset and
vect_use_strided_gather_scatters_p to get_load_store_type so
just called
The 11/06/2025 08:00, Tamar Christina wrote:
> Hi Alfie,
>
> > -Original Message-
> > From: Alfie Richards
> > Sent: 23 October 2025 14:31
> > To: [email protected]
> > Cc: Richard Earnshaw ; Tamar Christina
> > ; [email protected]; Alice Carlotti
> > ; Alex Coplan ; Wilco
> > Dij
Hi All,
Updated this patch to use r15 for argument passing (except on windows targets)
which I missed.
Updated the wording of the documentation and a comment slightly as it had caused
some confusion.
Reg tested on aarch64-linux-gnu.
Okay for master?
Alfie
-- >8 --
When applied to a function
PR libstdc++/122425
libstdc++-v3/ChangeLog:
* include/std/optional
(ranges::enable_borrowed_range>): Define.
* testsuite/20_util/optional/range.cc: Update tests.
---
libstdc++-v3/include/std/optional| 6 ++
libstdc++-v3/testsuite/20_util/option
This implements proposed resolution for LWG4308 [1].
For T denoting either function type or unbounded array, the optional no
longer exposes iterator, and viable begin/end members. The conditionally
provided iterator type, it is now defined in __optional_ref_iter_base
base class.
[1] https://cplus
Hi Tamar,
> On 28 Oct 2025, at 01:36, Tamar Christina wrote:
>
> For this example using the Adv.SIMD/SVE Bridge
>
> #include
> #include
> #include
>
> svint16_t sub_neon_i16_sve_bridged(svint8_t a, svint8_t b) {
>return svset_neonq_s16(svundef_s16(),
>vsubq_s16(vmovl_high_s8
The following should fix a disable-checking build which seems to
confuse gengtype.
Bootstrap with checking disabled running on x86_64-unknown-linux-gnu,
I'll push once that sufficiently progressed.
Richard.
* tree-core.h (tree_ssa_name::active_iterated_stmt): Mark
GTY((skip("")))
This patch implements _BitInt support for RISC-V target by defining the
type layout and ABI requirements. The limb mode selection is based on
the bit width, using appropriate integer modes from QImode to TImode.
The implementation also adds the necessary libgcc version symbols for
_BitInt runtime
> -Original Message-
> From: Alfie Richards
> Sent: 06 November 2025 10:01
> To: Tamar Christina ; [email protected]
> Cc: Richard Earnshaw ; [email protected];
> Alice Carlotti ; Alex Coplan
> ; Wilco Dijkstra ;
> [email protected]; [email protected]; [email protected];
>
XOR never received any attention when irange was enhanced for
sub-ranges, unlike AND and OR.
This patch also calculates XOR using its algebraic definition :
x ^ y = (x | y) & ~(x & y)
This utilizes the enhancements made to AND, OR and NOT to calculate
better ranges.
Legacy code can con
On Thu, 6 Nov 2025 at 14:04, Christophe Lyon via Sourceware Forge
wrote:
>
> Hi gcc-patches mailing list,
> Christophe Lyon has requested that the following forgejo
> pull request
> be published on the mailing list.
>
> Created on: 2025-10-14 20:19:29+00:00
> Latest update: 2025-11-06 13:03:10+0
Hi gcc-patches mailing list,
Christophe Lyon has requested that the following forgejo
pull request
be published on the mailing list.
Created on: 2025-10-14 20:19:29+00:00
Latest update: 2025-11-06 13:03:10+00:00
Changes: 5 changed files, 38 additions, 16 deletions
Head revision: clyon/gcc-TEST r
+ (svbool_t) {};
+ (svbool_t) { 0 };
+ (svbool_t) { sve_b1 };
+ (svbool_t) { gnu_u1 }; // { dg-error {cannot convert 'gnu_uint8_t'[^\n]* to
'signed char:1'} }
+ (svbool_t) { sve_s1 }; // { dg-error {cannot convert 'svint8_t' to 'signed
char:1'} }
+ (svbool_t) { sve_u1 }; // { dg-error {ca
On Thu, Nov 6, 2025 at 10:59 AM Robin Dapp wrote:
>
> > Yes, shifts are of the ugliest variant with all possible combinations of
> > scalar vs. vector, constant vs. non-constant present/not present on targets
> > ...
>
> Plus now the complication of 5 widening variants, even/odd, hi/lo. Will mos
Hi,
With the recent vectorizer changes the vectorizer can take care
of offset extension and scaling (and its proper costing) itself.
Thus, we can remove all related handling in expand_gather_scatter and
set the predicates in the gather/scatter expanders to what our
instructions actually support.
On 11/6/25 12:14 AM, Peter Damianov wrote:
This patch adds support for the BigObj COFF object file format to libiberty's
simple-object-coff.c. BigObj extends regular COFF to support a 32-bit section
count.
BigObj differs from COFF in a few ways:
* A different header structure
* 32-bit section c
Hi Claudiu,
I forgot to test the patch on top of trunk as well, which has now revealed some
tests failing. I will investigate further, in the meantime the patch should not
be applied.
Loeka
From: Luis Manuel Silva
Sent: Tuesday, November 4, 2025 15:12
> This patch would like to introduce the combine of vec_dup + vwmaccu.wv
> into vwmaccu.wx on the cost value of GR2VR. The late-combine will
> take place if the cost of GR2VRlike 1, 2, 15 in test.
>
> The combine only works from uint32_t to uint64_t widening.
The series is OK, thanks.
--
Regard
> I see, thanks Robin. Let's hold on for a while.
IMHO this can go forward now.
For documentation purposes: I experimented with adding widening shifts via
optabs/vectorizer directly and while it's possible it is IMHO too much rework.
There's a clear path forward:
- Make widen lshift an IFN,
On Thu, 6 Nov 2025, Avinash Jayakar wrote:
> On Thu, 2025-11-06 at 09:40 +0100, Richard Biener wrote:
> > On Thu, 6 Nov 2025, Avinash Jayakar wrote:
> >
> > > Hi,
> > >
> > > Based on the approach mentioned by Andrew, below is a patch to fix
> > > PR122126.
> > > Bootstrapped and regtested on po
Skip partial register clearing logic when dealing with FP_REGS in aggregates as
these are always fully cleared and the logic assumes a mask for each of the 4
argument GPR_REGS.
gcc/ChangeLog:
PR target/122539
* config/arm/arm.cc (comp_not_to_clear_mask_str_un): Skip partial
This series fixes the issue reported in PR 122539 by making sure we don't clear
registers in aggregates that have no padding. This applies to FP_REGs too, as
these are never padded.
The second patch in the series deals with an out-of-boudns access issue when
dealing with FP_REGs that was discover
On 06/11/2025 09:51, Tamar Christina wrote:
-Original Message-
From: Alfie Richards
Sent: 06 November 2025 09:47
To: Tamar Christina ; [email protected]
Cc: Richard Earnshaw ; [email protected];
Alice Carlotti ; Alex Coplan
; Wilco Dijkstra ;
[email protected]; [email protected]
> Yes, shifts are of the ugliest variant with all possible combinations of
> scalar vs. vector, constant vs. non-constant present/not present on targets
> ...
Plus now the complication of 5 widening variants, even/odd, hi/lo. Will most
likely defer this to the next stage 1.
In general, does it
> -Original Message-
> From: Alfie Richards
> Sent: 06 November 2025 09:47
> To: Tamar Christina ; [email protected]
> Cc: Richard Earnshaw ; [email protected];
> Alice Carlotti ; Alex Coplan
> ; Wilco Dijkstra ;
> [email protected]; [email protected]; [email protected];
>
This patch fixes the CMSE register clearing to make sure we don't clear
registers used by a function call. Before this patch the algorithm would only
correctly handle registers with padding bits to clear, any registers that were
fully utilised would be wrongfully cleared.
gcc/ChangeLog:
On Thu, 2025-11-06 at 09:40 +0100, Richard Biener wrote:
> On Thu, 6 Nov 2025, Avinash Jayakar wrote:
>
> > Hi,
> >
> > Based on the approach mentioned by Andrew, below is a patch to fix
> > PR122126.
> > Bootstrapped and regtested on powerpc64le and x86 with no
> > regressions. Kindly
> > review
On Thu, Nov 6, 2025 at 8:58 AM Robin Dapp wrote:
>
> Grml, this is turning into a rabbit hole.
>
> The initial plan was to "just" support the widening shift optab for riscv.
> This patch here was supposed to be the first step. The next patch adds
> support
> for n-n (SLP style) widening ops.
>
>
On Thu, 6 Nov 2025, Avinash Jayakar wrote:
> Hi,
>
> Based on the approach mentioned by Andrew, below is a patch to fix PR122126.
> Bootstrapped and regtested on powerpc64le and x86 with no regressions. Kindly
> review.
>
> Thanks and regards,
> Avinash Jayakar
>
> The function gimple_expand_ve
在 2025/11/5 下午6:47, Xi Ruoyao 写道:
It has turned out the normal code model isn't enough for some large
LoongArch link units in practice. Quoting WANG Rui's comment [1]:
We’ve actually been considering pushing for a change to the default
code model for LoongArch compilers (including GCC) for a
Hi Alfie,
> -Original Message-
> From: Alfie Richards
> Sent: 23 October 2025 14:31
> To: [email protected]
> Cc: Richard Earnshaw ; Tamar Christina
> ; [email protected]; Alice Carlotti
> ; Alex Coplan ; Wilco
> Dijkstra ; [email protected];
> [email protected]; sloosem...@bay
89 matches
Mail list logo
