[PATCH] libatomic: Provide __atomic_test_and_set() alias

If the target does not support the atomic_flag_test_and_set() operation in hardware, the compiler emits a call to __atomic_test_and_set(). However, libatomic provided only __atomic_test_and_set_1(). Provide __atomic_test_and_set() as an alias. libatomic/ChangeLog: * libatomic_i.h (EXPOR

Re: [PATCH] Change bellow in comments to below

On Thu 2025-07-10 08:09:50, Jakub Jelinek wrote: > Hi! > > While I'm not a native English speaker, I believe all the uses > of bellow (roar/bark/...) in comments in gcc are meant to be > below (beneath/under/...). FWIW I went through the patch and I agree that all of these should be 'below', not

[PATCH] Change bellow in comments to below

Hi! While I'm not a native English speaker, I believe all the uses of bellow (roar/bark/...) in comments in gcc are meant to be below (beneath/under/...). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2025-07-10 Jakub Jelinek gcc/ * tree-vect-loop.cc (scale_pro

[PATCH] RTEMS: Add riscv multilibs

gcc/ChangeLog: * config/riscv/t-rtems: Add -mstrict-align multilibs for targets without support for misaligned access in hardware. --- gcc/config/riscv/t-rtems | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/gcc/config/riscv/t-rtems b/gcc/config/ris

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

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) { return a(i); } else { return b(i); } }

[PATCH 2/2] RTEMS: Add sparc/leon5 multilibs

gcc/ChangeLog: * config/sparc/t-rtems: Add -mcpu=leon5 and -msoft-float -mcpu=leon5 multilibs. --- gcc/config/sparc/t-rtems | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems index 22c4a1b2635..a152a4c1d79

[PATCH 1/2] RTEMS: Format sparc/t-rtems

Change the format to easier associate multilib options with dirnames. gcc/ChangeLog: * config/sparc/t-rtems: Format. --- gcc/config/sparc/t-rtems | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems index beb

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

HI Honza, > On 9 Jul 2025, at 10:23 pm, Jan Hubicka wrote: > > External email: Use caution opening links or attachments > > >> >> I am seeing an ICEs in offline pass. >> >> >> during IPA pass: afdo_offline >> gmsh/src/mesh/meshGEdge.cpp:979:1: internal compiler error: in >> set_call_locati

RE: [PATCH v1] RISCV: Remove the v extension requirement for sat scalar run test

I see, thanks Jeff, just rerun it locally without new failures, will commit It soon. Pan -Original Message- From: Jeff Law Sent: Thursday, July 10, 2025 9:22 AM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com; Chen, Ken ; Liu,

Re: [PATCH v1] RISCV: Remove the v extension requirement for sat scalar run test

On 7/9/25 7:19 PM, Li, Pan2 wrote: * gcc.target/riscv/sat/sat_u_trunc-run-6-u8.c: Ditto. Spot checked. Note this uses "RISC-V" so it's not going to be picked up in the patchwork meeting. Oops, should be a typo here. It does seem to be causing some testing problems: It seems the

RE: [PATCH v1] RISCV: Remove the v extension requirement for sat scalar run test

>> * gcc.target/riscv/sat/sat_u_trunc-run-6-u8.c: Ditto. > Spot checked. Note this uses "RISC-V" so it's not going to be picked up > in the patchwork meeting. Oops, should be a typo here. > It does seem to be causing some testing problems: It seems the CI does pick up the latest code, I wi

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

Christophe, thank you very much for the detailed feedback. I re-posted the patches with your suggested changes to ChangeLog formatting, added line breaks for the long lines, and updated the test cases so you can now run them without the --target-board option. Regarding auto-merging, my changes a

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

This patch fixes PR117366: arm thumb1 epilogue size optimizer violates -ffixed-r4. gcc/ChangeLog: PR target/117366 * arm.cc (thumb1_extra_regs_pushed): Take fixed regs into account. --- diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc index bde06f3fa86..7bb829dbb04 100

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

This patch fixes PR117468: ARM thumb1 compilation using -ffixed-reg with r4-r7, without -Os (which prohibits use of high registers), produces bad high register restoration code that clobbers the fixed register. gcc/ChangeLog: PR target/117468 * arm.cc (thumb1_prologue_unused_call_c

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

On 7/9/25 2:36 PM, Jakub Jelinek wrote: On Wed, Jul 09, 2025 at 10:26:51AM -0400, Jason Merrill wrote: I don't understand this comment, at least in connection with the above snippet, that just handles the magic calls. Sorry I wasn't clear, the comment was about the existing code that follows t

Re: [PATCH v1 0/2] Allow targets to avoid materializing split parameters via stack extension [PR/82106]

On 7/3/25 3:50 PM, Palmer Dabbelt wrote: This is really Jim's code, but it's been sitting around in Bugzilla for a while so I've picked it up. All I really did here is add a target hook and mangle some comments, but I think I understand enough about what's going on to try and get things movin

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

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 breakages caused by P203

Re: Basic fusions in RISC-V generic tuning model

For statically scheduled superscalars that don't perform fusion, which is probably the common choice for statically scheduled designs, this change will generally be a deoptimization. For dynamically scheduled designs that don't perform fusion, it's probably more or less neutral. Not sure how these

[PATCH v2] libstdc++: Implement std::chrono::current_zone() for Windows

From: Björn Schäpers On Windows there is no API to get the current time zone as IANA name, instead Windows has its own zones. But there exists a mapping provided by the Unicode Consortium. This patch adds a script to convert the XML file with the mapping to a lookup table and adds a Windows code

Re: [PATCH] libstdc++: Implement std::chrono::current_zone() for Windows

Am 09.07.2025 um 16:16 schrieb Jonathan Wakely: On Wed, 9 Jul 2025 at 15:13, Jonathan Wakely wrote: On Tue, 8 Jul 2025 at 21:47, Björn Schäpers wrote: From: Björn Schäpers I have based this on my previous (not yet landed) patch, but it only reuses the #ifdef to include . Since std::array

Re: [PATCH v2] testsuite: arm: Update function body for scheduler

Hi Christophe, On 2025-07-09 17:31, Christophe Lyon wrote: On Wed, 9 Jul 2025 at 10:25, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-15? Changes since v1: - Removed the acceptance of LDR as it's only generated without r15-7373-g5163cf2ae14. Since I'm currently looking into gcc-

Re: [PATCH] aarch64: Extend HVLA permutations to big-endian

On Wed, Jul 9, 2025 at 7:07 AM Richard Sandiford wrote: > > TARGET_VECTORIZE_VEC_PERM_CONST has code to match the SVE2.1 > "hybrid VLA" DUPQ, EXTQ, UZPQ{1,2}, and ZIPQ{1,2} instructions. > This matching was conditional on !BYTES_BIG_ENDIAN. > > The ACLE code also lowered the associated SVE2.1 intr

Re: [PATCH] aarch64: Extend HVLA permutations to big-endian

On 7/9/25 11:00, Richard Sandiford wrote: External email: Use caution opening links or attachments Richard Sandiford writes: TARGET_VECTORIZE_VEC_PERM_CONST has code to match the SVE2.1 "hybrid VLA" DUPQ, EXTQ, UZPQ{1,2}, and ZIPQ{1,2} instructions. This ma

Re: [PATCH 7/7] aarch64: Use BSL2N for DImode operands

On 7/7/25 06:20, Kyrylo Tkachov wrote: > External email: Use caution opening links or attachments > > > Hi all, > > The intent of the patch is similar to previous in the series. > Make more use of BSL2N when we have DImode operands in SIMD regs, > but still use the GP instructions when that's wher

[PATCH v3] libstdc++: Simplify __uninitialized_default and __uninitialized_default_n

With improved memset optimizations in std::uninitialized_fill and std::uninitialized_fill_n (see r15-4473-g3abe751ea86e34), we can make the non-standard internal helpers __uninitialized_default and __uninitialized_default_n use those directly instead of using std::fill and std::fill_n respectively.

Re: [PATCH v5 16/24] c/c++: Add target_[version/clones] to decl diagnostics formatting.

On 5/29/25 8:52 AM, Alfie Richards wrote: Adds the target_version and target_clones attributes to diagnostic messages for target_version semantics. This is because the target_version/target_clones attributes affect the identity of the decls, so need to be represented in diagnostics for them. Af

Re: [PATCH v1] rs6000: Fix UBSAN runtime errors for powerpc64le-unknown-linux-gnu

Hi! On Wed, Jul 09, 2025 at 08:32:19PM +0530, Kishan Parmar wrote: > Ping! > > Please review. I did review this, in Message-ID: <20250626155019.go17...@gate.crashing.org> Date: Thu, 26 Jun 2025 10:50:19 -0500 https://inbox.sourceware.org/gcc-patches/20250626155019.go17...@gate.crashing.org/ Did

Re: [PATCH] aarch64: Fix endianness of DFmode vector constants

Hi Richard,   > aarch64_simd_valid_imm tries to decompose a constant into a repeating > series of 64 bits, since most Advanced SIMD and SVE immediate forms > require that.  (The exceptions are handled first.)  It does this by > building up a byte-level register image, lsb first.  If the image does

Re: [PATCH] tail-call: Allow tail recusion for classes with RVO (TREE_ADDRESSABLE set) [PR120871]

On 7/1/25 10:13 PM, Andrew Pinski wrote: With struct returns, we normally get a decl on the LHS of the call expression that will be tail called and we can match things up there easy. With TREE_ADDRESSABLE set on the type, things get more complex. Instead we get: ``` *_6(D) = get_s (1); [ret

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

Hi, Thanks for your patch, I think the same comments apply as the ones I just sent for your other patch (https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689121.html) Christophe On Thu, 26 Jun 2025 at 01:35, Matt Parks wrote: > > Fixing issue with thumb1 code generation clobbering register.

Re: [PATCH] RISC-V: Vector-scalar widening multiply-(subtract-)accumulate [PR119100]

Hi Robin, On 09/07/2025 11:11, Robin Dapp wrote: Hi Paul-Antoine, +;; Intermediate pattern for vfwmacc.vf and vfwmsac.vf used by combine +(define_insn_and_split "*extend_vf_" + [(set (match_operand:VWEXTF 0 "register_operand") +    (vec_duplicate:VWEXTF +  (float_extend: +    (match_op

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

Hi, Thanks for the patch, the code change looks sensible to me, but you'll have to wait for Richard (in cc) as he is the maintainer. However I have a few comments below: On Thu, 26 Jun 2025 at 00:57, Matt Parks wrote: > > Trying again, hopefully formatted correctly this time, and now including a

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Le 09/07/2025 à 08:50, Andre Vehreschild a écrit : HI Harald, hi Mikael, why shall the testcase be invalid? The `list` is empty. Concatenating with it is valid in Fortran like in most other programming languages. The mapping of an empty list in gfortran is to have the array's data pointer set to

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

On Wed, Jul 09, 2025 at 08:50:08AM +0200, Andre Vehreschild wrote: > > why shall the testcase be invalid? See the 2nd bullet in Fortran 2023, 9.7.1.3 Allocation of allocatable variables. An allocatable variable has a status of "unallocated" if it is not allocated. ... An allocata

[pushed] c++: add passing testcases [PR120243]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- These pass now; the first was fixed by r16-1507. PR c++/120243 gcc/testsuite/ChangeLog: * g++.dg/coroutines/torture/pr120243-unhandled-1.C: New test. * g++.dg/coroutines/torture/pr120243-unhandled-2.C: New test. --

[pushed] c++: generic lambda in template arg [PR121012]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- My r16-2065 adding missed errors for auto in a template arg in a lambda parameter also introduced a bogus error on this testcase, where the auto is both in a lambda parameter and in a template arg, but in the other order, which is OK. So we

[pushed] c++: 'this' in lambda in noexcept-spec [PR121008]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In r16-970 I changed finish_this_expr to look at current_class_type rather than current_class_ptr to accommodate explicit object lambdas. But here in a lambda in the noexcept-spec, the closure type doesn't yet have the function as its conte

Re: [PATCH v1] RISCV: Remove the v extension requirement for sat scalar run test

On 7/8/25 11:07 PM, pan2...@intel.com wrote: From: Pan Li The sat scalar run test should not require the v extension, thus take rv32 || rv64 instead of riscv_v for the requirement. The below test suites are passed for this patch series. * The rv64gcv fully regression test. * The rv32gcv ful

Re: [PATCH] Make the RTL frontend set REG_NREGS correctly

On Wed, Jul 9, 2025 at 4:05 PM Richard Sandiford wrote: > > While working on a new testcase that uses the RTL frontend, > I hit a bug where a (reg ...) that spans multiple hard registers > had REG_NREGS set to 1. This caused various things to misbehave. > For example, if the (reg ...) in question

Re: [PATCH v2] testsuite: arm: Update function body for scheduler

On Wed, 9 Jul 2025 at 10:25, Torbjörn SVENSSON wrote: > > Ok for trunk and releases/gcc-15? > > Changes since v1: > - Removed the acceptance of LDR as it's only generated without > r15-7373-g5163cf2ae14. Since > I'm currently looking into gcc-14 release, and made the patch in that > scope, I r

Re: [PATCH] c++: optional template after :: causing error [PR119838]

On 7/8/25 4:22 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Found while working on Reflection where we currently reject: constexpr auto r = ^^::template C::type; which should work, because "::template C::" should match the nested-name-sp

Re: [PATCH] aarch64: Some fixes for SVE INDEX constants

On Wed, Jul 9, 2025 at 7:09 AM Richard Sandiford wrote: > > When using SVE INDEX to load an Advanced SIMD vector, we need to > take account of the different element ordering for big-endian > targets. For example, when big-endian targets store the V4SI > constant { 0, 1, 2, 3 } in registers, 0 bec

Re: [PATCH v1] rs6000: Fix UBSAN runtime errors for powerpc64le-unknown-linux-gnu

Ping! Please review. Thanks & Regards, Kishan On 26/06/25 1:26 pm, Kishan Parmar wrote: > Hi All, > > The following patch has been bootstrapped and regtested on powerpc64le-linux. > > While building GCC with --with-build-config=bootstrap-ubsan on > powerpc64le-unknown-linux-gnu, multiple UBSAN ru

Re: [PATCH] aarch64: Extend HVLA permutations to big-endian

Richard Sandiford writes: > TARGET_VECTORIZE_VEC_PERM_CONST has code to match the SVE2.1 > "hybrid VLA" DUPQ, EXTQ, UZPQ{1,2}, and ZIPQ{1,2} instructions. > This matching was conditional on !BYTES_BIG_ENDIAN. > > The ACLE code also lowered the associated SVE2.1 intrinsics into > suitable VEC_PERM_

Re: [PATCH v1] rs6000: Restore opaque overload variant for correct diagnostics

Ping! please review. Thanks & Regards Kishan On 05/06/25 12:36 pm, Kishan Parmar wrote: > Hi All, > > The following patch has been bootstrapped and regtested on powerpc64le-linux. > > After r12-5752-gd08236359eb229, a new bif infrastructure was introduced > which stopped using opaque vector type

Re: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.

On Jul 09 2025, Robert Dubner wrote: > An attempt to override that with > > make CFLAGS-cobol/genapi.o=-DHARMLESS > > has no effect on the value of the CFLAGS-cobol/genapi.o If you are doing this from the toplevel then it's because only known variables are passed to subdirs. -- Andreas Sc

Re: [PATCH] RISC-V: Enable zvfh for vector-scalar half-float run tests

On 7/8/25 9:17 AM, Paul-Antoine Arras wrote: zvfh is not enabled at the testsuite level. It has to be enabled on a testcase by testcase basis. This was correctly done for compile tests but not for run tests. This patch fixes it. Also, to ensure correct results with half-precision floats, MAX_R

RE: [PATCH] RISC-V: Adjust testdata for unsigned vector SAT_SUB

Thanks Jeff and Kito, LGTM. Pan -Original Message- From: Jeff Law Sent: Wednesday, July 9, 2025 10:33 PM To: Ciyan Pan ; gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com; richard.guent...@gmail.com; tamar.christ...@arm.com; juzhe.zh...@rivai.ai; Li, Pan2 ; rdapp@gmail.com Subject:

RE: [PATCH v1 0/3] RISC-V: Combine vec_duplicate + vssub.vv to vssub.vx on GR2VR cost

Thanks Robin. The failures of FAIL: gcc.dg/vect/vect-strided-a-u8-i2-gap.c -flto -ffat-lto-objects (test for excess errors) from the linux-rv64gcv-lp64d testsuite log should not be a real failure (build failure but run success). It passed locally as below, so will commit it soon. Executing on

Re: [PATCH] RISC-V: Adjust testdata for unsigned vector SAT_SUB

On 7/9/25 2:35 AM, Ciyan Pan wrote: From: panciyan This patch adjust test data for unsigned vector SAT_SUB to vec_sat_data.h Passed the rv64gcv regression test. Signed-off-by: Ciyan Pan gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/sat/vec_sat_arith.h: Add vec_sat_u_s

Re: [PATCH v2 1/1] libiberty: add routines to handle type-sensitive doubly linked lists

Matthieu Longo writes: > Those methods's implementation is relying on duck-typing at compile > time. > The structure corresponding to the node of a doubly linked list needs > to define attributes 'prev' and 'next' which are pointers on the type > of a node. > The structure wrapping the nodes and o

RE: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.

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 point where gcc/cobol files are compiled, the environment variable has this value:

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

On 7/9/25 9:30 AM, Jakub Jelinek wrote: On Tue, Jul 08, 2025 at 09:43:20PM -0400, Jason Merrill wrote: @@ -3066,7 +3810,12 @@ cxx_eval_call_expression (const constexp return arg1; } else if (cxx_dynamic_cast_fn_p (fun)) - return cxx_eval_dynamic_cast_fn (ctx, t,

Re: [PATCH] ext-dce: Fix subreg_lsb is_constant assumption

On 7/9/25 8:00 AM, Richard Sandiford wrote: Makes me wonder if I should resurrect my aarch64_be RFS. I changed how those systems worked in the system a few years back to make it work better with container based testing rather than direct chroots. I never converted aarch64_be to that setup

Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

Hi Jerry, good you could build Toon's code. Your idea of using the OpenCoarray tests to test caf_shmem made me think about how to do it the easiest. I came up with the following: 1. Pull a recent OpenCoarray source tree from Github or use a clean existing one. 2. Apply attached patch. 3. Crea

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

On 7/9/25 7:34 AM, Jakub Jelinek wrote: On Tue, Jul 08, 2025 at 09:43:20PM -0400, Jason Merrill wrote: Thanks for the review. Working on the rest (most of it already have in my working copy). case CLEANUP_POINT_EXPR: { - auto_vec cleanups; + auto_vec cleanups; What

Re: [PATCH] libstdc++: Implement std::chrono::current_zone() for Windows

On Wed, 9 Jul 2025 at 15:13, Jonathan Wakely wrote: > > On Tue, 8 Jul 2025 at 21:47, Björn Schäpers wrote: > > > > From: Björn Schäpers > > > > I have based this on my previous (not yet landed) patch, but it only > > reuses the #ifdef to include . Since std::array isn't used > > anywhere else I

[PATCH] aarch64: Fix endianness of DFmode vector constants

aarch64_simd_valid_imm tries to decompose a constant into a repeating series of 64 bits, since most Advanced SIMD and SVE immediate forms require that. (The exceptions are handled first.) It does this by building up a byte-level register image, lsb first. If the image does turn out to repeat eve

Re: [PATCH] libstdc++: Implement std::chrono::current_zone() for Windows

On Tue, 8 Jul 2025 at 21:47, Björn Schäpers wrote: > > From: Björn Schäpers > > I have based this on my previous (not yet landed) patch, but it only > reuses the #ifdef to include . Since std::array isn't used > anywhere else I thought that was the right place to put it. > > I hope the formatting

[PATCH] aarch64: Some fixes for SVE INDEX constants

When using SVE INDEX to load an Advanced SIMD vector, we need to take account of the different element ordering for big-endian targets. For example, when big-endian targets store the V4SI constant { 0, 1, 2, 3 } in registers, 0 becomes the most significant element, whereas INDEX always operates fr

[PATCH] aarch64: Extend HVLA permutations to big-endian

TARGET_VECTORIZE_VEC_PERM_CONST has code to match the SVE2.1 "hybrid VLA" DUPQ, EXTQ, UZPQ{1,2}, and ZIPQ{1,2} instructions. This matching was conditional on !BYTES_BIG_ENDIAN. The ACLE code also lowered the associated SVE2.1 intrinsics into suitable VEC_PERM_EXPRs. This lowering was not conditio

[PATCH] Make the RTL frontend set REG_NREGS correctly

While working on a new testcase that uses the RTL frontend, I hit a bug where a (reg ...) that spans multiple hard registers had REG_NREGS set to 1. This caused various things to misbehave. For example, if the (reg ...) in question was used as crtl->return_rtx, only the first register in the group

Re: [PATCH] ext-dce: Fix subreg_lsb is_constant assumption

Jeff Law writes: > On 7/4/25 10:21 AM, Richard Sandiford wrote: >> ext-dce had: >> >>if (SUBREG_P (dst) && SUBREG_BYTE (dst).is_constant ()) >> { >>bit = subreg_lsb (dst).to_constant (); >>if (bit >= HOST_BITS_PER_WIDE_INT) >> bit = HOST_BITS_

[pushed] testsuite: Add a couple of fstack_protector guards

These tests required runtime support for -fstack-protector, but didn't test for it. Tested on aarch64-linux-gnu and aarch64_be-elf & pushed as obvious. Richard gcc/testsuite/ * gcc.target/aarch64/pr118348_1.c: Require fstack_protector. * gcc.target/aarch64/pr118348_2.c: Likewise

Re: [PUSHED] Fix 'main' function in 'gcc.dg/builtin-dynamic-object-size-pr120780.c'

On 2025-07-09 04:21, Thomas Schwinge wrote: Fix-up for commit 72e85d46472716e670cbe6e967109473b8d12d38 "tree-optimization/120780: Support object size for containing objects". 'size_t sz' is unused here, and GCC/nvptx doesn't accept this: spawn -ignore SIGHUP [...]/nvptx-none-run ./builtin-

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

On 2025-07-08 18:18, Qing Zhao wrote: On Jul 8, 2025, at 17:46, Siddhesh Poyarekar wrote: On 2025-07-08 17:17, Qing Zhao wrote: Are the above the correct and efficient updates to the .ACCESS_WITH_SIZE to resolve both PR121000 and the issue we have with counted_by for pointers? I don't know

[to-be-committed][RISC-V] Detect new fusions for RISC-V

This is primarily Daniel's work... He's chasing things in QEMU & LLVM right now so I'm doing a bit of clean-up and shepherding this patch forward. -- Instruction fusion is a reasonably common way to improve the performance of code on many architectures/designs. A few years ago we submitted

[PATCH v5 2/3] Error handling for hard register constraints

This implements error handling for hard register constraints including potential conflicts with register asm operands. In contrast to register asm operands, hard register constraints allow more than just one register per operand. Even more than just one register per alternative. For example, a v

[PATCH v5 1/3] Hard register constraints

Implement hard register constraints of the form {regname} where regname must be a valid register name for the target. Such constraints may be used in asm statements as a replacement for register asm and in machine descriptions. A more verbose description is given in extend.texi. It is expected a

[PATCH v5 3/3] genoutput: Verify hard register constraints

Since genoutput has no information about hard register names we cannot statically verify those names in constraints of the machine description. Therefore, we have to do it at runtime. Although verification shouldn't be too expensive, restrict it to checking builds. This should be sufficient since

[PATCH v5 0/3] Hard Register Constraints

This is a follow-up to https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684181.html I added the last missing pieces namely changelogs, and bootstrapped and regtested on aarch64-unknown-linux-gnu powerpc64le-unknown-linux-gnu s390x-ibm-linux-gnu x86_64-pc-linux-gnu Via cross compilers I verifie

Re: [PATCH 2/2] tree-optimization/109893 - allow more backwards jump threading

On 7/9/25 7:17 AM, Richard Biener wrote: ISTR the backwards threader simply cancels paths that had blocks in common with another jump thread (that happened to be materialized first). But maybe it's less strict than that. It cancels things in too many places and while it collects all opport

Basic fusions in RISC-V generic tuning model

One thing I forgot to bring up in the patchwork meeting yesterday. Philip or Craig asked if we should add the most basic fusions to the generic tuning models for the two toolchains. I'm generally in favor of making that kind of change. I don't think anyone believes it'd be a major performanc

[PATCH 3/3] Remove vect_dissolve_slp_only_groups

This function dissolves DR groups that are not subject to SLP. Which means it is no longer necessary. Bootstrap and regtest running on x86_64-unknown-linux-gnu. * tree-vect-loop.cc (vect_dissolve_slp_only_groups): Remove. (vect_analyze_loop_2): Do not call it. --- gcc/tree-vect-

[PATCH 2/3] Remove vect_analyze_loop_operations

This removes the remains of vect_analyze_loop_operations. All the checks it does still on LC PHIs of inner loops in outer loop vectorization should be handled by vectorizable_lc_phi. Bootstrap and regtest running on x86_64-unknown-linux-gnu. * tree-vect-loop.cc (vect_active_double_reduct

[PATCH 1/3] Remove non-SLP vectorization factor determining

The following removes the VF determining step from non-SLP stmts. For now we keep setting STMT_VINFO_VECTYPE for all stmts, there are too many places to fix, including some more complicated ones, so this is defered for a followup. Along this removes vect_update_vf_for_slp, merging the check for pr

Re: [PATCH 2/2] tree-optimization/109893 - allow more backwards jump threading

On Wed, Jul 9, 2025 at 3:06 PM Jeff Law wrote: > > > > On 7/9/25 6:53 AM, Richard Biener wrote: > > On Wed, Jul 9, 2025 at 2:16 PM Jeff Law wrote: > >> > >> > >> > >> On 7/9/25 12:27 AM, Richard Biener wrote: > >>> The following changes the percentage that determines how many > >>> stmts are allo

[PATCH v5 11/11] openmp, fortran: Add support for non-constant iterator bounds in Fortran deep-mapping iterator support

This patch adds support for non-constant iterator bounds to the Fortran deep-mapping iterator support. To do this, we need to keep track of the new iterator entries generated during by the deep mapping. Code is generated by lower_omp_target to allocate memory for each of these entries one-by-o

[PATCH v5 7/11] openmp: Add macros for iterator element access

This patch adds macros to refer to the fields of OpenMP iterators by name rather than by index, as the number of items has increased to 10 and referring to them by index has become error-prone.From e09f6cba88e321e9da50e002b3e74ff36cf19865 Mon Sep 17 00:00:00 2001 From: Kwok Cheung Yeung Date: Sa

Re: [PATCH 2/2] tree-optimization/109893 - allow more backwards jump threading

On 7/9/25 6:53 AM, Richard Biener wrote: On Wed, Jul 9, 2025 at 2:16 PM Jeff Law wrote: On 7/9/25 12:27 AM, Richard Biener wrote: The following changes the percentage that determines how many stmts are allowed for backwards jump threading from 50 to 54, enabling the missed jump threading

[PATCH v5 10/11] openmp, fortran: Add iterator support for Fortran, deep-mapping of allocatables

This patch adds iterator support for Fortran deep mapping of allocatables. When a new map is generated in gfc_omp_deep_mapping_map, a new elements array is allocated in the iterator loop, and the data and size that would have gone into the map are now written into the array from inside the ite

[PATCH v5 8/11] openmp: Fix struct handling for OpenMP iterators

This patch fixes some issues with the struct handling introduced in the patch for Fortran support. The problem is that build_omp_struct_comp_nodes and omp_accumulate_sibling_list can add extra clauses with iterators onto the target construct, but this occurs after the iterator loop has already

Re: [PATCH 1/3]middle-end: support vec_cbranch_any and vec_cbranch_all [PR118974]

On Wed, 9 Jul 2025, Tamar Christina wrote: > (on mobile so doing a top reply) > > > So it isn't as efficient to use cbranch_any (g != 0) here? I think it > > should be practically equivalent... > > Ah yeah, it can expand what we currently expand vector boolean to. > > I was initially confuse

[wwwdocs] Add some C++23 and C++26 library features to GCC 16 release notes

Also thank Tomasz for std::format range support in GCC 15 --- Pushed to wwwdocs. htdocs/gcc-15/changes.html | 2 +- htdocs/gcc-16/changes.html | 21 - 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html inde

[PATCH v2 0/1] libiberty: add routines to handle type-sensitive doubly linked lists

This patch was originally part of [1]. Merging it in GCC is a prerequisite of merging it inside binutils. Those methods's implementation is relying on duck-typing at compile time. The structure corresponding to the node of a doubly linked list needs to define attributes 'prev' and 'next' which

[PATCH v5 9/11] openmp: Add support for using custom mappers with iterators (C, C++)

This patch adds support for custom mappers with iterators (C and C++ only, as the Fortran custom mapper support has not been committed yet, nor has support for nested mappers). It works by propagating clause iterators onto new clauses generated by mappers. As this occurs early in the front-end

Re: [PATCH 2/2] tree-optimization/109893 - allow more backwards jump threading

On Wed, Jul 9, 2025 at 2:16 PM Jeff Law wrote: > > > > On 7/9/25 12:27 AM, Richard Biener wrote: > > The following changes the percentage that determines how many > > stmts are allowed for backwards jump threading from 50 to 54, > > enabling the missed jump threading observed in PR109893. > > > >

[PATCH v5 4/11] openmp, fortran: Add support for map iterators in OpenMP target construct (Fortran)

v2: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662142.html v3: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664546.html v4: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670337.html Again, largely the same as v4, with a couple of extra bug-fixes: - When computin

[PATCH v2 1/1] libiberty: add routines to handle type-sensitive doubly linked lists

Those methods's implementation is relying on duck-typing at compile time. The structure corresponding to the node of a doubly linked list needs to define attributes 'prev' and 'next' which are pointers on the type of a node. The structure wrapping the nodes and others metadata (first, last, size) n

Re: [PATCH v1 1/1] libiberty: add common methods for type-sensitive doubly linked lists

On 2025-07-08 16:25, Richard Sandiford wrote: Matthieu Longo writes: Those methods's implementation is relying on duck-typing at compile time. The structure corresponding to the node of a doubly linked list needs to define attributes 'prev' and 'next' which are pointers on the type of a node. T

[PATCH v5 6/11] openmp: Add support for non-constant iterator parameters in map, to and from clauses

The previous version was posted at: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671630.html This patch is largely the same as the previous version, but calculation of the size of the iterator elements array is separated into another function for reuse later.From 607ceefb93136fd14471

Re: [PATCH 2/2] tree-optimization/109893 - allow more backwards jump threading

On Wed, 9 Jul 2025, Jan Hubicka wrote: > > The following changes the percentage that determines how many > > stmts are allowed for backwards jump threading from 50 to 54, > > enabling the missed jump threading observed in PR109893. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu. It

[PATCH v5 5/11] openmp, fortran: Add support for iterators in OpenMP 'target update' constructs (Fortran)

v2: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662143.html v3: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664548.html v4: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670338.html This is largely identical to v4 of the patch, with some slightly improved error

[PATCH v5 3/11] openmp: Add support for iterators in 'target update' clauses (C/C++)

V1: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652683.html V2: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662141.html V3: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664545.html V4: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670336.html This patch is

[PATCH v5 2/11] openmp: Add support for iterators in map clauses (C/C++)

v1: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652682.html v2: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662140.html v3: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664543.html v4: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670335.html This patch is

Re: [PATCH 1/3]middle-end: support vec_cbranch_any and vec_cbranch_all [PR118974]

(on mobile so doing a top reply) > So it isn't as efficient to use cbranch_any (g != 0) here? I think it > should be practically equivalent... Ah yeah, it can expand what we currently expand vector boolean to. I was initially confused because for SVE what we want here is an ORRS (flag settin

[PATCH v5 1/11] openmp: Refactor handling of iterators

V1: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652681.html V2: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662139.html V3: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664542.html V4: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670334.html This patch is

Re: [PATCH v1 1/3] libstdc++: Implement is_sufficiently_aligned.

On Thu, 3 Jul 2025 at 11:35, Luc Grosheintz wrote: > > This commit implements and tests the function is_sufficiently_aligned > from P2897R7. > > libstdc++-v3/ChangeLog: > > * include/bits/align.h (is_sufficiently_aligned): New function. > * include/bits/version.def (is_sufficiently

[PATCH v5 0/11] openmp: Add support for iterators in OpenMP mapping clauses

This is yet another revision of the patch series posted at: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670333.html and incorporates the non-constant iterator bounds support posted at: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671630.html Compared to the previous patch s

Re: [PATCH 2/2] tree-optimization/109893 - allow more backwards jump threading

> The following changes the percentage that determines how many > stmts are allowed for backwards jump threading from 50 to 54, > enabling the missed jump threading observed in PR109893. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. It seems that > at least backward threading is prone

  1   2   >