Re: [PATCH v1 1/2] Match: Leverage BITS_PER_WORD for unsigned SAT_MUL pattern

On Fri, Jul 11, 2025 at 6:51 AM wrote: > > From: Pan Li > > The widen mul has different source type for differnt platform, > like rv32 or rv64. For rv32, the source of widen mul is 32-bits > while 64-bits in rv64. Thus, leverage HOST_WIDE_INT is not that > correct and result in the pattern matc

Re: [PATCH] ipa: Disallow signature changes in fun->has_musttail functions [PR121023]

On Fri, 11 Jul 2025, Jakub Jelinek wrote: > Hi! > > As the following testcase shows e.g. on ia32, letting IPA opts change > signature of functions which have [[{gnu,clang}::musttail]] calls > can turn programs that would be compiled normally into something > that is rejected because the caller ha

RE: [PATCH] Reject single lane vector types for SLP build

On Thu, 10 Jul 2025, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Thursday, July 10, 2025 6:42 PM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ; > > CI RISC-V > > Subject: Re: [PATCH] Reject single lane vector types for S

[PATCH v1 2/2] RISC-V: Add testcase for rv32 SAT_MUL from uint64

From: Pan Li Add the run and asm testcase for rv32 SAT_MUL, widen mul from uint8_t, uint16_t, uint32_t to uint64_t. gcc/testsuite/ChangeLog: * gcc.target/riscv/sat/sat_u_mul-1-u16-from-u64.c: New test. * gcc.target/riscv/sat/sat_u_mul-1-u32-from-u64.c: New test. * gcc.ta

[PATCH v1 1/2] Match: Leverage BITS_PER_WORD for unsigned SAT_MUL pattern

From: Pan Li The widen mul has different source type for differnt platform, like rv32 or rv64. For rv32, the source of widen mul is 32-bits while 64-bits in rv64. Thus, leverage HOST_WIDE_INT is not that correct and result in the pattern match failures in 32-bits system like rv32. Thus, levera

[PATCH v1 0/2] Refine the unsigned SAT_MUL for 32-bits like rv32

From: Pan Li The widen mul has different source type for differnt machines, like rv32 or rv64. The SAT_MUL pattern doesn't works well for backend like rv32 in previous, thus we would like to refine it by BITS_PER_WORD for precision check. The below test suites are passed for this patch: 1. The

RE: [PATCH] RISC-V: Add testcases for unsigned vector SAT_SUB form 11 and form 12

Ok, thanks. Pan -Original Message- From: Ciyan Pan Sent: Friday, July 11, 2025 10:35 AM To: gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com; richard.guent...@gmail.com; tamar.christ...@arm.com; juzhe.zh...@rivai.ai; Li, Pan2 ; jeffreya...@gmail.com; rdapp@gmail.com; panciyan Sub

[PATCH v2] x86: Update MMXMODE:*mov_internal to support all 1s vectors

commit 77473a27bae04da99d6979d43e7bd0a8106f4557 Author: H.J. Lu Date: Thu Jun 26 06:08:51 2025 +0800 x86: Also handle all 1s float vector constant replaces (insn 29 28 30 5 (set (reg:V2SF 107) (mem/u/c:V2SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64])) 2031 {*movv2sf_inte

คุณเดือดร้อน เราช่วยคุณได้ ไม่มีโอนก่อนไม่มีมัดจำ

[PATCH] RISC-V: Add testcases for unsigned vector SAT_SUB form 11 and form 12

From: panciyan This patch adds testcase for form11 and form12, as shown below: void __attribute__((noinline)) \ vec_sat_u_sub_##T##_fmt_11 (T *out, T *op_1, T *op_2, unsigned limit) \ {\ u

Re: [PATCH 1/2] [APX CFCMOV] Support APX CFCMOV in if_convert pass

Ping, hopefully someone can help review this part Hongyu Wang 于2025年5月21日周三 09:09写道： > > From: Lingling Kong > > Hi, > > APX CFCMOV feature implements conditionally faulting which means > that all memory faults are suppressed when the condition code > evaluates to false and load or store a memor

Re: [PATCH] libstdc++: Fix __uninitialized_default for constexpr case

On Tue, 8 Jul 2025, Jonathan Wakely wrote: > We should not use the std::fill optimization for trivial types during > constant evaluation, because we need to begin the lifetime of all > objects, even trivially default constructible ones. > > This fixes a bug that Clang diagnosed: > > include/c++/

Re: [PATCH] x86: Update "*mov_internal" in mmx.md to handle all 1s vectors

On Thu, Jul 10, 2025 at 9:44 PM Uros Bizjak wrote: > > On Thu, Jul 10, 2025 at 2:31 PM Uros Bizjak wrote: > > > > On Thu, Jul 10, 2025 at 1:57 PM H.J. Lu wrote: > > > > > > commit 77473a27bae04da99d6979d43e7bd0a8106f4557 > > > Author: H.J. Lu > > > Date: Thu Jun 26 06:08:51 2025 +0800 > > > >

[PATCH] [arm] prevent impossible tail- long-calls with static chain [PR119430]

When a function call uses up all argument registers, and needs IP for the static chain, there isn't any call-clobbered register left for reload to assign as the sibcall target, when -mlong-calls is enabled. Use the same logic that does the job for indirect calls to prevent tail calls in this case

Re: [PATCH 2/2] libstdc++: Always treat __float128 as a floating-point type

On Wed, 9 Jul 2025, Jonathan Wakely wrote: > Similar to the previous commit that made is_integral_v<__int128> > unconditionally true, this makes is_floating_point_v<__float128> > unconditionally true. With the new extended floating-point types in > C++23 (std::float64_t etc.) it seems unhelpful fo

Re: [PATCH 1/2] libstdc++: Treat __int128 as a real integral type [PR96710]

On Wed, 9 Jul 2025, Jonathan Wakely wrote: > Since LWG 3828 (included in C++23) implementations are allowed to have > extended integer types that are wider than intmax_t. This means we no > longer have to make is_integral_v<__int128> false for strict -std=c++23 > mode, removing the confusing incon

[PATCH] ipa: Disallow signature changes in fun->has_musttail functions [PR121023]

Hi! As the following testcase shows e.g. on ia32, letting IPA opts change signature of functions which have [[{gnu,clang}::musttail]] calls can turn programs that would be compiled normally into something that is rejected because the caller has fewer argument stack slots than the function being ta

[PATCH] c++, v3: Implement C++26 P2786R13 - Trivial Relocatability [PR119064]

On Thu, Jul 10, 2025 at 05:46:06PM -0400, Jason Merrill wrote: > > + bool trivially_relocatable_if_eligible : 1; > > + bool replaceable_if_eligible : 1; > > + > > + bool trivially_relocatable : 1; > > + bool trivially_relocatable_computed : 1; > > + bool replaceable : 1; > > + bool replaceabl

Re: [PATCH] c++: Save 8 further bytes from lang_type allocations

On 6/9/25 1:30 PM, Jakub Jelinek wrote: Hi! The following patch implements the /* FIXME reuse another field? */ comment on the lambda_expr member. I think (and asserts in the patch seem to confirm) CLASSTYPE_KEY_METHOD is only ever non-NULL for TYE_POLYMORPHIC_P and on the other side CLASSTYPE_

Re: [PATCH] c++, v2: Implement C++26 P2786R13 - Trivial Relocatability [PR119064]

On 6/17/25 2:25 AM, Jakub Jelinek wrote: Hi! When writing the libstdc++ patch, I've noticed I've missed adding any testsuite coverage for __builtin_is_nothrow_relocatable trait. And got wrong the implementation as well, I thought type2 in that case should be the rvalue reference type to type1,

Re: [PATCH] c++: Fix up final handling in C++98 [PR120628]

On 6/12/25 3:11 AM, Jakub Jelinek wrote: Hi! The following patch is on top of the https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686210.html patch which stopped treating override as conditional keyword in class properties. This PR mentions another problem; we emit a bogus warning on code li

[pushed] aarch64: Guard VF-based costing with !m_costing_for_scalar

g:4b47acfe2b626d1276e229a0cf165e934813df6c caused a segfault in aarch64_vector_costs::analyze_loop_vinfo when costing scalar code, since we'd end up dividing by a zero VF. Much of the structure of the aarch64 costing code dates from a stage 4 patch, when we had to work within the bounds of what th

Re: [PATCH] c++, v2: Don't incorrectly reject override after class head name [PR120569]

On 6/9/25 1:19 PM, Jakub Jelinek wrote: On Mon, Jun 09, 2025 at 12:17:12PM -0400, Jason Merrill wrote: While the https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#c03-compatibility-changes-for-annex-c-diff.cpp03.dcl.dcl hunk dropped because struct C {}; struct C {} final {};

[RFC v2] c++: Quoting in -fmodules-mapper [PR110153]

Users might be using a space in their build directory path. To allow specifying such a root for the module mapper started by GCC, we need the command to allow quotes. Previously quoting a path passed to the module mapper was not possible, so replace the custom argv parsing with the argv parsing log

[pushed] testsuite: Fix unallocated array usage in test

Le 08/07/2025 à 22:17, Harald Anlauf a écrit : A corresponding fix is approved. For some reason the sanitizers didn't work on my machine, they didn't work on cfarm135, but I was able to confirm they were catching an error on the testcase on cfarm421. Now fixed.From ca034694757f0fb3461a1d0c

Re: [PATCH] c, c++: Extend -Wunused-but-set-* warnings [PR44677]

On 4/24/25 3:50 AM, Jakub Jelinek wrote: Hi! The -Wunused-but-set-* warnings work by using 2 bits on VAR_DECLs & PARM_DECLs, TREE_USED and DECL_READ_P. If neither is set, we typically emit -Wunused-variable or -Wunused-parameter warning, that is for variables which are just declared (including

Re: [PATCH v3] arm.cc: fix thumb1 size-optimized function prolog violates -ffixed-rX [PR117366]

Thanks for the update. Like in your other email, there are still formatting issues. Here is the version I applied manually and used in CI. Christophe On Thu, 10 Jul 2025 at 01:46, Matt Parks wrote: > > This patch fixes PR117366: > arm thumb1 epilogue size optimizer violates -ffixed-r4. > > gcc

Re: [PATCH v2] arm.cc: fix thumb1 prologue high reg restore violates -ffixed-rX [PR117468]

Hi, Thanks for the update. There are still some formatting problems, some of which might be caused by your mailer. I manually applied the patch and manually triggered CI, the new test passed without regression. Here is the version I tested, let's wait for Richard's feedback. Christophe On Thu

Re: [PATCH, v2] Fortran: fix minor issues with coarrays (extended)

Hi Andre, Am 10.07.25 um 13:24 schrieb Andre Vehreschild: Hi Harald, sorry for all the confusion. Probably my understanding of a pure elemental routine is imperfect. I therefore first like to express what I need an a caf-accessor. In a caf-accessor I have only access to data that is "exported"

Re: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.

On Tue, 8 Jul 2025 16:59:36 -0500 (CDT) Robert Dubner wrote: > > Does that not suffice? > > I don't think it does. > > I am forced, for roughly the fourth time, to establish my > requirements: > > 1) I want, for development, to be able to establish flags for the > COBOL front end -- independen

[PATCH 1/3] fortran: Generate array reallocation out of loops

From: Mikael Morin Regression tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Generate the array reallocation on assignment code before entering the scalarization loops. This doesn't move the generated code itself, which was already put before the outermost loop, but only changes the cu

[PATCH 2/3] fortran: Delay evaluation of array bounds after reallocation

From: Mikael Morin Regression tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Delay the evaluation of bounds, offset, etc after the reallocation, for the scalarization of allocatable arrays on the left hand side of assignments. Before this change, the code preceding the scalarization lo

[PATCH 3/3] fortran: Amend descriptor bounds init if unallocated

From: Mikael Morin Regression tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Always generate the conditional initialization of unallocated variables regardless of the basic variable allocation tracking done in the frontend and with an additional always false condition. The scalarizer u

[PATCH 0/3] fortran: Reallocation on assignment tweaks

From: Mikael Morin Hello, here are three patches as follow-up to this message. These started as an attempt to remove the PR fortran/108889 workaround, which I didn't understand. I had to keep it in the end but this is what I could save from that failed attempt. Regression tested on x86_64-pc-li

Re: [RFC] c++: Quoting in -fmodules-mapper [PR110153]

On Thu, Jul 10, 2025 at 12:05 PM Nicolas Werner wrote: > > Users might be using a space in their build directory path. To allow > specifying such a root for the module mapper started by GCC, we need the > command to allow quotes. Previously quoting a path passed to the module > mapper was not poss

RE: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.

Excerpts from Robert Dubner's message of Juli 9, 2025 4:32 pm: > With respect, this is another example of "I have been unable to make it > work." > > The gcc/Makefile.in has this line in it: > > $(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += > -DIN_GCC_FRONTEND)) > > At the po

[RFC] c++: Quoting in -fmodules-mapper [PR110153]

Users might be using a space in their build directory path. To allow specifying such a root for the module mapper started by GCC, we need the command to allow quotes. Previously quoting a path passed to the module mapper was not possible, so replace the custom argv parsing with wordexp(), which sup

RE: [PATCH] Reject single lane vector types for SLP build

> -Original Message- > From: Richard Biener > Sent: Thursday, July 10, 2025 6:42 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ; > CI RISC-V > Subject: Re: [PATCH] Reject single lane vector types for SLP build > > > > > Am 10.07.2025 um 16:27 schrieb Tamar

[PATCH] testsuite: Disable musttail tests if target uses SJLJ exceptions

A few tests started failing recently on pru-unknown-elf because it uses SJLJ implementation for exceptions: FAIL: g++.dg/ext/musttail3.C -std=c++11 (test for excess errors) .../gcc/gcc/testsuite/g++.dg/ext/musttail3.C:12:34: error: cannot tail-call: caller uses sjlj exceptions Fix by disabli

Re: [PATCH] c++: P2036R3 - Change scope of lambda trailing-return-type [PR102610]

On 7/9/25 4:27 PM, Marek Polacek wrote: On Tue, Jul 08, 2025 at 12:15:03PM -0400, Jason Merrill wrote: On 7/7/25 4:52 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This patch is an attempt to implement P2036R3 along with P2579R0, fixing build br

Re: [PATCH 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

On Thu, Jul 10, 2025 at 05:49:53PM +, Qing Zhao wrote: > One more note here, previously, ACCESS_MODE has 5 values: > -1: Unknown access semantics > 0: none > 1: read_only > 2: write_only > 3: read_write > > For counted_by, I passed “-1” to the .ACCESS_WITH_SIZE. >

Re: [PATCH 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

> On Jul 10, 2025, at 13:53, Jakub Jelinek wrote: > > On Thu, Jul 10, 2025 at 05:49:53PM +, Qing Zhao wrote: >> One more note here, previously, ACCESS_MODE has 5 values: >> -1: Unknown access semantics >> 0: none >> 1: read_only >> 2: write_only >> 3: read_write >>

[To-commit][PATCH v2 1/2] Passing TYPE_SIZE_UNIT of the element as the 6th argument to .ACCESS_WITH_SIZE (PR121000)

This is the 2nd version based on Jacub's comments: a. Update the changelog; b. Update the testing case; bootstrapped and tested. I will commit this version soon. thanks. Qing. === The size of the element of the FAM _cannot_ reliably depends on the original

[To-commit][PATCH v2 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

This is the 2nd version of the patch. update the changelog per Jacub's comments. I will commit this version soon. thanks. Qing This is an improvement to the design of internal function .ACCESS_WITH_SIZE. Currently, the .ACCESS_WITH_SIZE is designed as: ACCESS_WI

Re: [PATCH 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

> On Jul 10, 2025, at 13:27, Qing Zhao wrote: > > > >> On Jul 10, 2025, at 12:56, Jakub Jelinek wrote: >> >> On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote: >>> gcc/c-family/ChangeLog: >>> >>> * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position >>> of the argumen

Re: [PATCH 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

On Thu, Jul 10, 2025 at 05:27:50PM +, Qing Zhao wrote: > ACCESS_MODE is only for a future work to reimplement the attribute > access with the internal function .ACCESS_WITH_SIZE. > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute > > For th

Re: [PATCH] Reject single lane vector types for SLP build

> Am 10.07.2025 um 16:27 schrieb Tamar Christina : > >  >> >> -Original Message- >> From: Richard Biener >> Sent: Thursday, July 10, 2025 3:09 PM >> To: Tamar Christina >> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ; >> RISC-V CI >> Subject: RE: [PATCH] Reject single lane vecto

Re: [PATCH 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

> On Jul 10, 2025, at 12:56, Jakub Jelinek wrote: > > On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote: >> gcc/c-family/ChangeLog: >> >> * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position >> of the arguments per the new design. >> >> gcc/c/ChangeLog: >> >> * c-typec

Re: [PATCH 1/2] Passing TYPE_SIZE_UNIT of the element as the 6th argument to .ACCESS_WITH_SIZE (PR121000)

> On Jul 10, 2025, at 12:34, Jakub Jelinek wrote: > > On Thu, Jul 10, 2025 at 04:03:29PM +, Qing Zhao wrote: >> The size of the element of the FAM _cannot_ reliably depends on the original >> TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE: >> >> TYPE_SIZE

Re: [PATCH] c++, libstdc++, v5: Implement C++26 P3068R5 - constexpr exceptions [PR117785]

On 7/10/25 4:05 AM, Jakub Jelinek wrote: On Wed, Jul 09, 2025 at 06:45:41PM -0400, Jason Merrill wrote: + && reduced_constant_expression_p (val)) And a value doesn't need to be constant to be printable, we should be able to print it unconditionally. Sure, the question is if printing

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

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/.gitignore @@ -0,0 +1,23 @@ +.gitignore_local +.python-version +#

Re: [PATCH 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote: > gcc/c-family/ChangeLog: > > * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position > of the arguments per the new design. > > gcc/c/ChangeLog: > > * c-typeck.cc (build_counted_by_ref): Update comments. >

Re: [PATCH 1/2] Passing TYPE_SIZE_UNIT of the element as the 6th argument to .ACCESS_WITH_SIZE (PR121000)

On Thu, Jul 10, 2025 at 04:03:29PM +, Qing Zhao wrote: > The size of the element of the FAM _cannot_ reliably depends on the original > TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE: > > TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5 > >

Re: [Patch, Fortran, Coarray, PR88076, v2] Add a shared memory multi process coarray library.

Am 10.07.25 um 11:27 schrieb Andre Vehreschild: Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Did you run extensive tests on all potential race conditions, and fix the resulting fallout? If you did, please post your test cases and the results. Otherwise, https://gcc.gnu.org/piperm

[PATCH 1/2] Passing TYPE_SIZE_UNIT of the element as the 6th argument to .ACCESS_WITH_SIZE (PR121000)

The size of the element of the FAM _cannot_ reliably depends on the original TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE: TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5 when the element of the FAM has a variable length type. Since the vari

[PATCH 2/2] Reduce the # of arguments of .ACCESS_WITH_SIZE from 6 to 4.

This is an improvement to the design of internal function .ACCESS_WITH_SIZE. Currently, the .ACCESS_WITH_SIZE is designed as: ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE, TYPE_OF_SIZE, ACCESS_MODE, TYPE_SIZE_UNIT for element) which returns the REF_TO_OBJ sa

Re: [PATCH] aarch64: Fix LD1Q and ST1Q failures for big-endian

On Thu, Jul 10, 2025 at 6:22 AM Richard Sandiford wrote: > > LD1Q gathers and ST1Q scatters are unusual in that they operate > on 128-bit blocks (effectively VNx1TI). However, we don't have > modes or ACLE types for 128-bit integers, and 128-bit integers > are not the intended use case. Instead,

Re: [PATCH V2] testsuite: Fix gcc.target/powerpc/vsx-builtin-7.c test [PR119382]

Hi Surya, Jeevitha, On Thu, Jul 10, 2025 at 08:26:51PM +0530, Surya Kumari Jangala wrote: > On 24/06/25 3:30 pm, jeevitha wrote: > > The following patch has been tested on powerpc64le-linux and verified it's > > fixed. > > > > Changes from V1: > > Added the reason for adding the flag(-fno-ipa-icf

Re: [PATCH] tree-optimization/120939 - remove uninitialized use of LOOP_VINFO_COST_MODEL_THRESHOLD

Richard Biener writes: > The following removes an optimization that wrongly triggers right now > because it accesses LOOP_VINFO_COST_MODEL_THRESHOLD which might not be > computed yet. > > Testing on x86_64 didn't reveal any testsuite coverage. > > Bootstrapped and tested on x86_64-unknown-linux-gn

Re: [PATCH V2] testsuite: Fix gcc.target/powerpc/vsx-builtin-7.c test [PR119382]

Hi Jeevitha, On 24/06/25 3:30 pm, jeevitha wrote: > Hi All, > > The following patch has been tested on powerpc64le-linux and verified it's > fixed. > > Changes from V1: > Added the reason for adding the flag(-fno-ipa-icf) inside the test case. > > The test vsx-builtin-7.c failed on powerpc64le-

Re: [PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion

On 7/10/25 8:37 AM, Jan Dubiec wrote: On 10.07.2025 15:42, Jeff Law wrote: [...] Anyway, this has been repeatedly bootstrapped & regression tested on aarch64, ppc64le and other targets.  It's also been many dozens of regression testing cycles on the various embedded targets. This part of c

[PATCH] RISC-V: Improve bswap8 when zbb is enabled

This peephole pattern combines the following instructions: bswap8: rev8a5,a0 -> li a4,-65536 -> sraia5,a5,32 -> and a5,a5,a4 -> roriw a5,a5,16 and a0,a0,a4 or a0,a0,a5 sext.w a0,a0 ret And emits th

Re: [PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion

On 10.07.2025 15:42, Jeff Law wrote: [...] Anyway, this has been repeatedly bootstrapped & regression tested on aarch64, ppc64le and other targets.  It's also been many dozens of regression testing cycles on the various embedded targets. This part of code does not seem to be used on many targe

RE: [PATCH] Reject single lane vector types for SLP build

> -Original Message- > From: Richard Biener > Sent: Thursday, July 10, 2025 3:09 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ; > RISC-V CI > Subject: RE: [PATCH] Reject single lane vector types for SLP build > > On Thu, 10 Jul 2025, Tamar Christina wrote: >

[PATCH] s390: Support global stack protector canary

So far only a per thread canary in the TLS block is supported. This patch adds support for a global canary, too. For this the new option -mstack-protector-guard={global,tls} is added which defaults to tls. The global canary is expected at symbol __stack_chk_guard which means for a function prolo

RE: [PATCH] Reject single lane vector types for SLP build

On Thu, 10 Jul 2025, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Thursday, July 10, 2025 1:31 PM > > To: gcc-patches@gcc.gnu.org > > Cc: Richard Sandiford ; Tamar Christina > > ; RISC-V CI > > Subject: [PATCH] Reject single lane vector types for SLP b

[PATCH] arm: Fix CMSE nonecure calls [PR 120977]

As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685733.html the operand of the call should be a mem rather than an unspec. This patch moves the unspec to an additional argument of the parallel and adjusts cmse_nonsecure_call_inline_register_clear accordingly. The scan-rtl-dump

Re: [PATCH] gcov: Split atomic bitwise-or for some targets

On 7/9/25 11:53 PM, Sebastian Huber wrote: There are targets, which only offer 32-bit atomic operations (for example 32-bit RISC-V). For these targets, split the 64-bit atomic bitwise-or operation into two parts. For this test case int a(int i); int b(int i); int f(int i) { if (i) {

Re: [PING][PATCH] config/rs6000/t-float128: Don't encode full build paths into headers

Hi! On Thu, Jul 10, 2025 at 12:10:16PM +, Sadineni, Harish wrote: > Ping for [1]https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html. > > This patch avoids embedding full build paths into generated headers by using > only the basename of the source file. This helps to improve bui

RE: [PATCH] Reject single lane vector types for SLP build

> -Original Message- > From: Richard Biener > Sent: Thursday, July 10, 2025 1:31 PM > To: gcc-patches@gcc.gnu.org > Cc: Richard Sandiford ; Tamar Christina > ; RISC-V CI > Subject: [PATCH] Reject single lane vector types for SLP build > > The following makes us never consider vector(1) T

Re: [PATCH] x86: Update "*mov_internal" in mmx.md to handle all 1s vectors

On Thu, Jul 10, 2025 at 2:31 PM Uros Bizjak wrote: > > On Thu, Jul 10, 2025 at 1:57 PM H.J. Lu wrote: > > > > commit 77473a27bae04da99d6979d43e7bd0a8106f4557 > > Author: H.J. Lu > > Date: Thu Jun 26 06:08:51 2025 +0800 > > > > x86: Also handle all 1s float vector constant > > > > replaces

Re: [PATCH] [x86] properly compute fp/mode for scalar ops for vectorizer costing

On Thu, 10 Jul 2025, Jan Hubicka wrote: > > The x86 add_stmt_hook relies on the passed vectype to determine > > the mode and whether it is FP for a scalar operation. This is > > unreliable now for stmts involving patterns and in the future when > > there is no vector type passed for scalar operat

Re: [PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion

On 2/22/25 8:10 AM, Jan Dubiec wrote: This patch fixes SFtype to UDWtype (aka float to unsigned long long) conversion on targets without DFmode like e.g. H8/300H. It solely relies on SFtype->UWtype and UWtype->UDWtype conversions/casts. The existing code in line 2218 (counter = a) assigns/cast

Re: [AutoFDO] Fix get_original_name to strip only names that are generated after auto-profile

Hi, this patch fixes several issues I noticed in gimple matching and -Wauto-profile warning. One problem is that we mismatched symbols with user names, such as "*strlen" instead of "strlen". I added raw_symbol_name to strip extra '*' which is ok on ELF targets which are only targets we support wit

Re: [PATCH] [x86] properly compute fp/mode for scalar ops for vectorizer costing

> The x86 add_stmt_hook relies on the passed vectype to determine > the mode and whether it is FP for a scalar operation. This is > unreliable now for stmts involving patterns and in the future when > there is no vector type passed for scalar operations. > > To be least disruptive I've kept using

[pushed] testsuite: Add -funwind-tables to sve*/pfalse* tests

The SVE svpfalse folding tests use CFI directives to delimit the function bodies. That requires -funwind-tables to be enabled, which is true by default for *-linux-gnu targets, but not for *-elf. Tested on aarch64-linux-gnu and aarch64_be-elf. Pushed as obvious. Richard gcc/testsuite/

[PATCH] [x86] properly compute fp/mode for scalar ops for vectorizer costing

The x86 add_stmt_hook relies on the passed vectype to determine the mode and whether it is FP for a scalar operation. This is unreliable now for stmts involving patterns and in the future when there is no vector type passed for scalar operations. To be least disruptive I've kept using the vector

[PATCH] tree-optimization/120939 - remove uninitialized use of LOOP_VINFO_COST_MODEL_THRESHOLD

The following removes an optimization that wrongly triggers right now because it accesses LOOP_VINFO_COST_MODEL_THRESHOLD which might not be computed yet. Testing on x86_64 didn't reveal any testsuite coverage. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK? PR tree-optimizatio

[PATCH] aarch64: Fix LD1Q and ST1Q failures for big-endian

LD1Q gathers and ST1Q scatters are unusual in that they operate on 128-bit blocks (effectively VNx1TI). However, we don't have modes or ACLE types for 128-bit integers, and 128-bit integers are not the intended use case. Instead, the instructions are intended to be used in "hybrid VLA" operations

[PATCH v3 1/1] aarch64: Fold builtins with highpart args to highpart equivalent [PR117850]

Add a fold at gimple_fold_builtin to prefer the highpart variant of a builtin if at least one argument is a vector highpart and any others are VECTOR_CSTs that we can cheaply extend to 128-bits. This eliminates data movement instructions. For example, we prefer UMULL2 here over DUP+UMULL uint16x

[PATCH v3 0/1] aarch64: Fold builtins with highpart args to highpart equivalent [PR117850]

Hi all, This is V3 of a fix for PR117850. V2 wasn't picked up or pinged by me as my work changed quickly, so I've taken the opportunity here to fix it up a bit. The major differences from V1 are based on the feedback given there. There are two things that I'd like to note: * This fold i

Rewrite assign_discriminators pass

Hi, to assign debug locations to corresponding statements auto-fdo uses discriminators. Documentation says that if given statement belongs to multiple basic blocks, the discrminator distinguishes them. Current implementation however only work fork statements that expands into a squence of gimple

Re: [PATCH] x86: Update "*mov_internal" in mmx.md to handle all 1s vectors

On Thu, Jul 10, 2025 at 1:57 PM H.J. Lu wrote: > > commit 77473a27bae04da99d6979d43e7bd0a8106f4557 > Author: H.J. Lu > Date: Thu Jun 26 06:08:51 2025 +0800 > > x86: Also handle all 1s float vector constant > > replaces > > (insn 29 28 30 5 (set (reg:V2SF 107) > (mem/u/c:V2SF (symbol

[PATCH] Reject single lane vector types for SLP build

The following makes us never consider vector(1) T types for vectorization and ensures this during SLP build. This is a long-standing issue for BB vectorization and when we remove early loop vector type setting we lose the single place we have that rejects this for loops. Once we implement partial

[PING][PATCH] config/rs6000/t-float128: Don't encode full build paths into headers

Hi all, Ping for https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html. This patch avoids embedding full build paths into generated headers by using only the basename of the source file. This helps to improve build reproducibility, particularly in environments where build paths vary

[PATCH] MicroBlaze : Enhance support for atomics. Fix PR118280

namaskaaram Please find the patch attached. This addresses regression for MicroBlaze (PR118280) Atomic support enhanced to fix existing atomic_compare_and_swapsi pattern to handle side effects; new patterns atomic_fetch_op and atomic_test_and_set added. As MicroBlaze has no QImode test/set instru

[PATCH] x86: Update "*mov_internal" in mmx.md to handle all 1s vectors

commit 77473a27bae04da99d6979d43e7bd0a8106f4557 Author: H.J. Lu Date: Thu Jun 26 06:08:51 2025 +0800 x86: Also handle all 1s float vector constant replaces (insn 29 28 30 5 (set (reg:V2SF 107) (mem/u/c:V2SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64])) 2031 {*movv2sf_inte

Re: [PATCH] aarch64: Enable selective LDAPUR generation for cores with RCPC2

Soumya AR writes: >> On 10 Jul 2025, at 3:15 PM, Richard Sandiford >> wrote: >> >> External email: Use caution opening links or attachments >> >> >> Soumya AR writes: On 1 Jul 2025, at 9:22 PM, Kyrylo Tkachov wrote: > On 1 Jul 2025, at 17:36, Richard Sandiford >

Re: [PATCH v3 2/9] opts: use uint64_t for sanitizer flags

On Thu, Jul 10, 2025, 4:12 AM wrote: > From: Indu Bhagat > > Currently, the data type of sanitizer flags is unsigned int, with > SANITIZE_SHADOW_CALL_STACK (1UL << 31) being highest individual > enumerator for enum sanitize_code. Use 'uint64_t' data type to allow > for more distinct instrumenta

Re: [PATCH, v2] Fortran: fix minor issues with coarrays (extended)

Hi Harald, sorry for all the confusion. Probably my understanding of a pure elemental routine is imperfect. I therefore first like to express what I need an a caf-accessor. In a caf-accessor I have only access to data that is "exported" to it via the add_data object. The data in there has to be ma

Re: [PATCH] aarch64: Enable selective LDAPUR generation for cores with RCPC2

> On 10 Jul 2025, at 3:15 PM, Richard Sandiford > wrote: > > External email: Use caution opening links or attachments > > > Soumya AR writes: >>> On 1 Jul 2025, at 9:22 PM, Kyrylo Tkachov wrote: >>> >>> >>> On 1 Jul 2025, at 17:36, Richard Sandiford wrote: Soumya

[PATCH 5/5] Handle failed gcond pattern gracefully

SLP analysis of early break conditions asserts pattern recognition canonicalized all of them. But the pattern can fail, for example when vector types cannot be computed. So be graceful here, so we don't ICE when we didn't yet compute vector types. Bootstrapped and tested on x86_64-unknown-linux-

[PATCH v3 7/9] asan: memtag-stack add support for MTE instructions

From: Claudiu Zissulescu Memory tagging is used for detecting memory safety bugs. On AArch64, the memory tagging extension (MTE) helps in reducing the overheads of memory tagging: - CPU: MTE instructions for efficiently tagging and untagging memory. - Memory: New memory type, Normal Tagged Mem

[PATCH 4/5] Adjust reduction with conversion SLP build

The following adjusts how we set SLP_TREE_VECTYPE for the conversion node we build when fixing up the reduction with conversion SLP instance. This should probably see more TLC, but the following avoids relying on STMT_VINFO_VECTYPE for this. * tree-vect-slp.cc (vect_build_slp_instance): D

[PATCH 3/5] Avoid vect_is_simple_use call from vectorizable_reduction

When analyzing the reduction cycle we look to determine the reduction input vector type, for lane-reducing ops we look at the input but instead of using vect_is_simple_use which is problematic for SLP we should simply get at the SLP operands vector type. If that's not set and we make up one we sho

[PATCH v3 5/9] targhooks: add TARGET_MEMTAG_COMPOSE_OFFSET_TAG

From: Claudiu Zissulescu Add a new target hook TARGET_MEMTAG_COMPOSE_OFFSET_TAG to perform addition between two tags. The default of this hook is to byte add the inputs. Hardware-assisted sanitizers on architectures providing instructions to compose (add) two tags like in the case of AArch64.

[PATCH v3 4/9] aarch64: add new constants for MTE insns

From: Indu Bhagat Define new constants to be used by the MTE pattern definitions. gcc/ * config/aarch64/aarch64.md (MEMTAG_TAG_MASK): New define constant. (MEMTAG_ADDR_MASK): Likewise. (irg, subp, ldg): Use new constants. Signed-off-by: Claudiu Zissulescu ---

[PATCH 2/5] Avoid vect_is_simple_use call from get_load_store_type

This isn't the required refactoring of vect_check_gather_scatter but it avoids a now unnecessary call to vect_is_simple_use which is problematic because it looks at STMT_VINFO_VECTYPE which we want to get rid of. SLP build already ensures vect_is_simple_use on all lane defs, so all we need is to p

Re: [PATCH] expand: ICE if asked to expand RDIV with non-float type.

On Thu, Jul 10, 2025 at 12:38 PM Robin Dapp wrote: > > Hi, > > this patch adds asserts that ensure we only expand an RDIV_EXPR with > actual float mode. It also replaces the RDIV_EXPR in setting a > vectorized loop's length by EXACT_DIV_EXPR. The code in question is > only used with length-contr

[PATCH 1/5] Pass SLP node down to cost hook for reduction cost

The following arranges vector reduction costs to hand down the SLP node (of the reduction stmt) to the cost hooks, not only the stmt_info. This also avoids accessing STMT_VINFO_VECTYPE of an unrelated stmt to the node that is subject to code generation. * tree-vect-loop.cc (vect_model_red

  1   2   >