Re: [PATCH v2] RISC-V: Support RVVDImode for avg3_floor auto vect

The avg3_floor pattern leverage the add and shift rtl with the DOUBLE_TRUNC mode iterator. Aka, RVVDImode iterator will generate avg3rvvsimode_floor, only the element size QI, HI and SI are allowed. Thus, this patch would like to support the DImode by the standard name, with the iterator V_VLSI_

Re: [PATCH] RISC-V: Fix vsetvl merge rule.

On 7/14/25 7:55 AM, Robin Dapp wrote: Hi, In PR120297 we fuse  vsetvl e8,mf2,...  vsetvl e64,m1,... into  vsetvl e64,m4,... Individually, that's ok but we also change the new vsetvl's demand to "SEW only" even though the first original one demanded SEW >= 8 and ratio = 16. As we forget t

[PATCH] tree-optimization/121059 - fixup loop mask query

When we opportunistically mask an operand of a AND with an already available loop mask we need to query that set with the correct number of masks we expect. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/121059 * tree-vect-stmts.cc (vectorizable_

Re: [PATCH 1/2] libstdc++: Add missing initializers for __maybe_present_t members [PR119962]

On Tue, 15 Jul 2025, Jonathan Wakely wrote: > On Tue, 15 Jul 2025 at 08:26, Tomasz Kaminski wrote: > > > > > > > > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote: > >> > >> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps > >> 15? Not sure if this corner case is worth

[COMMITTED] asf: Fix offset check in base reg initialization for big-endian targets

During the base register initialization, in the case that we are eliminating the load instruction, we are using `offset == 0` in order to find the store instruction that has the same offset as the load. This would not work on big-endian targets where byte 0 would be the MS byte. This patch updates

Re: [PATCH] aarch64: Use SVE2 BSL2N for vector EON

> On 15 Jul 2025, at 15:50, Richard Sandiford wrote: > > Kyrylo Tkachov writes: >> Hi all, >> >> SVE2 BSL2N (x, y, z) = (x & z) | (~y & ~z). When x == y this computes: >> (x & z) | (~x & ~z) which is ~(x ^ z). >> Thus, we can use it to match RTL patterns (not (xor (...) (...))) for both >> Ad

Re: [PATCH 2/2] libstdc++: Conditionalize LWG 3569 changes to join_view

On Tue, 15 Jul 2025, Tomasz Kaminski wrote: > > > On Tue, Jul 15, 2025 at 3:55 PM Patrick Palka wrote: > On Tue, 15 Jul 2025, Tomasz Kaminski wrote: > > > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka > wrote: > >       Tested on x86_64-pc-linux-gnu, does this look OK for t

Re: [PATCH v2 1/1] contrib: add bpf-vmtest-tool to test BPF programs

Hi Piyush. This form of the script looks generally good to me. May be a good time to move to the second stage of the project, which if I am not mistaken consists in creating some dejagnu infrastructure so we can get testsuites running the script on the test sources. At this point it would be g

Re: [PATCH v2 1/1] contrib: add bpf-vmtest-tool to test BPF programs

On 7/10/25 10:21, Piyush Raj wrote: > Hi David, > > On 09/07/25 03:33, David Faust wrote: >>> diff --git a/contrib/bpf-vmtest-tool/.gitignore >>> b/contrib/bpf-vmtest-tool/.gitignore >>> new file mode 100644 >>> index 000..723dfe1d0f4 >>> --- /dev/null >>> +++ b/contrib/bpf-vmtest-tool

ACCESS_WITH_SIZE for pointers Re: [PATCH] tree-optimization/120929: Limit MEM_REF handling to .ACCESS_WITH_SIZE

Hi, I wrote a small writeup to summarize the two approaches to generate .ACCESS_WITH_SIZE for pointers with counted_by, In this writeup, I described the major issue for the approach we agreed on last week to fix PR120929, due to the problem, the previous implementation in the committed (and rev

Re: [PATCH v2 1/1] contrib: add bpf-vmtest-tool to test BPF programs

Hi Jose, On 15/07/25 22:55, Jose E. Marchesi wrote: Hi Piyush. This form of the script looks generally good to me. May be a good time to move to the second stage of the project, which if I am not mistaken consists in creating some dejagnu infrastructure so we can get testsuites running the scr

Re: [PATCH] libstdc++: Ensure that ranges::destroy destroys in constexpr [PR121024]

On Mon, Jul 14, 2025 at 10:41 PM Jonathan Wakely wrote: > The new test is currently marked as XFAIL because PR c++/102284 means > that GCC doesn't notice that the lifetimes have ended. > > libstdc++-v3/ChangeLog: > > PR libstdc++/121024 > * include/bits/ranges_uninitialized.h (ran

[COMMITTED] Fix tree.cc compilation on SPARC

commit 4d7baa94a48c27030c8ffcfaf3dd187be09903a9 Author: Andrew Pinski Date: Sun Jul 13 11:56:03 2025 -0700 tree: Add include to tm_p.h to tree.cc [PR120866] broke SPARC bootstrap: In file included from ./tm_p.h:4, from /vol/gcc/src/hg/master/local/gcc/tree.cc:35: /vol/gcc

Re: [PATCH] libstdc++: Make ranges::advance(it, n, bound) follow standard more strictly

On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely wrote: > The standard specifies some of the effects of ranges::advance in terms > of "Equivalent to:" and it's observable that our current implementation > deviates from the precise specification in the standard. This was > causing some failures i

Re: [PATCH] libstdc++: Make all experimental::observer_ptr functions constexpr

On Mon, Jul 14, 2025 at 2:00 PM Jonathan Wakely wrote: > I've just created LWG 4295 proposing this change, and am implementing it > via this patch. > > libstdc++-v3/ChangeLog: > > * include/experimental/memory (swap, make_observer_ptr): Add > constexpr. > (operator==, oper

Re: [PATCH v5] RISC-V: Mips P8700 Conditional Move Support.

Hi @Jeff Law and all, https://patchwork.sourceware.org/project/gcc/patch/20250715053410.557741-1-ukalappa.m...@gmail.com/ looks ok to us ,please let me any comments for your end , Thank you ~U On Tue, Jul 15, 2025 at 11:04 AM Umesh Kalappa wrote: > Updated the test for rv32 accordingly and

RE: [PATCH 1/1] aarch64: Adapt unwinder to linux's SME signal behaviour

Hi Yury, This looks in general OK to me (Thanks for the clear comments!), but had some questions: > -Original Message- > From: Yury Khrustalev > Sent: Thursday, June 19, 2025 2:40 PM > To: gcc-patches@gcc.gnu.org > Cc: Richard Sandiford ; Mark Rutland > > Subject: [PATCH 1/1] aarch64:

Re: [PATCH] libstdc++: Define std::nothrow as inline variable

On Mon, Jul 14, 2025 at 10:43 PM Jonathan Wakely wrote: > This makes it possible to use `new(std::nothrow) X` without linking to > libsupc++ or libstdc++. > > To ensure we still export the symbol from the library we need to > suppress the inline variable in libsupc++/new_handler.cc which is done

[PING*4][PATCH 1/1] config: Handle dash in library name for AC_LIB_LINKAGEFLAGS_BODY

Ping for: https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656541.html Thanks & Best Regards Abdul Basit -Original Message- From: Ijaz, Abdul B Sent: Friday, January 10, 2025 9:10 PM To: gcc-patches@gcc.gnu.org Cc: Ijaz, Abdul B Subject: [PING*3][PATCH 1/1] config: Handle dash in li

Re: [PATCH] i386: Decouple AMX-AVX512 from AVX10.2 and imply AVX512F

On Tue, Jul 15, 2025 at 2:36 PM Haochen Jiang wrote: > > Hi all, > > In ISE058, the AVX10.2 imply is removed from AMX-AVX512. This > leads to re-consideration on the imply for AMX-AVX512. > > Since it is using zmm register and using zmm register only, we > need to at least imply AVX512F. AVX512VL

Re: [PATCH 1/1] aarch64: Adapt unwinder to linux's SME signal behaviour

Tamar Christina writes: > One question I did have not directly related to the unwinder changes, > But the ABI mentions that if any of the reserved bytes in TPIDR2_EL0 > Block are non-zero that TPIDR2_EL0 must be left unchanged [1]. The full requirement is: If TPIDR2_EL0 is nonnull and if any r

Re: [PATCH 2/2] libstdc++: Conditionalize LWG 3569 changes to join_view

On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only > (since it impacts ABI)? > In theory an Iterator that meets all semantic requirements of the input_iterator concept, could provide a default constructor that is unconstrained, b

Re: [PATCH 4/7] aarch64: Use EOR3 for DImode values

I had pushed this patch on Friday but have reverted it on trunk now because it seems to be causing miscomputes in 531.deepsjeng_r. Thanks, Kyrill > On 8 Jul 2025, at 08:28, Tamar Christina wrote: > >> -Original Message- >> From: Kyrylo Tkachov >> Sent: Monday, July 7, 2025 11:19 AM >>

<    1   2