Re: [PATCH 0/1] [RFC][AutoFDO]: Source filename tracking in GCOV

Hi Honza, > On 8 Jul 2025, at 10:31 pm, Jan Hubicka wrote: > > External email: Use caution opening links or attachments > > >> Hi Honza, >> >>> On 8 Jul 2025, at 2:26 am, Jan Hubicka wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> >>> Hi, >>> as discussed a

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

This patch would like to introduce the combine of vec_dup + vssub.vv into vssub.vx on the cost value of GR2VR. The late-combine will take place if the cost of GR2VR is zero, or reject the combine if non-zero like 1, 2, 15 in test. There will be two cases for the combine: Jeff has already pre-a

Re: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.

On Jul 08 2025, Robert Dubner wrote: > Are you suggesting that I can somehow apply a specific set of flags when > compiling, for example, > > gcc/cobol/genapi.cc > > If so, how could I do that? There are some examples in gcc/Makefile.in. CFLAGS-cobol/genapi.o = ... -- Andreas Schwab, SUS

Re: [PATCH 2/3] tree: Add 7 and 8 argument TREE_CHECK_* and TREE_NOT_CHECK_*

On Wed, Jul 9, 2025 at 4:36 AM Alex (Waffl3x) wrote: > Adding extra checks like this is OK. Thanks, Richard.

Re: [PATCH 3/3] middle-end/121005 Add checks for TREE_LANG_FLAG_*

On Wed, Jul 9, 2025 at 4:37 AM Alex (Waffl3x) wrote: > /* Nonzero in a _DECL if the use of the name is defined as an unavailable feature by __attribute__((unavailable)). */ #define TREE_UNAVAILABLE(NODE) \ - ((NODE)->base.u.bits.unavailable_flag) + ((TREE_CHECK_BITS_AVAILABLE (NODE))->ba

Re: [PATCH 1/3] tree: Add TREE_NOT_RANGE_CHECK

On Wed, Jul 9, 2025 at 4:37 AM Alex (Waffl3x) wrote: > LGTM. Richard.

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

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_sub_fmt wrap define. * gcc.target/r

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

On 7/9/25 3:11 AM, Robin Dapp wrote: Also, seems like the CI picked up the patch but didn't run it? Yea, it's happened with a couple of mine recently, including one yesterday. If it's not picked up when Paul-Antoine posts an update, then I'll throw it into my system for some degree of pr

Re: [PATCH] [PR target/109286] H8/300: Fix warnings about initfini sections missing attributes

On 7/8/25 10:26 AM, Jan Dubiec wrote: The patch changes order of inclusions, i.e. elfos.h is included before target specific h8300/h8300.h, in a way similar to a few other targets. Thanks to this change it is possible to override macros from elfos.h in h8300/h8300.h, in particular .init/.fini

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

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. Bootstrapped and tested on x86_64-unknown-linux-gnu. It seems that at

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] 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] 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] 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] 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 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

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] 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] aarch64: Implement sme2+faminmax extension.

Hi Alfie, > On 7 Jul 2025, at 10:46, Alfie Richards wrote: > > Hello all, > > This patch implements the couple of amin/amax instructions that are part of > SME2 + faminmax. > > Regression testsed and bootstrapped for Aarch64. > > Thanks, > Alfie > > -- >8 -- > > Implements the sme2+faminmax

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

On Wed, 9 Jul 2025, Tamar Christina wrote: > > > +Operand 0 is a comparison operator. Operand 1 and operand 2 are the > > > +first and second operands of the comparison, respectively. Operand 3 > > > +is the @code{code_label} to jump to. > > > + > > > +@cindex @code{cbranch_all@var{mode}4} instr

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

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's the rationale for this increase

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

On 7/9/25 4:51 AM, Kito Cheng wrote: OK if Pan say OK Note the CI failure is unrelated to Ciyan Pan's work. Looks like something went goofy in the libstdc++ space. I'm running it through my tester right now. jeff

[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] 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

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] 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] 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] 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, 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

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

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-dynamic-object-size-pr120780.exe error :

Re: [PATCH] libstdc++: Members missing in std::numeric_limits

Thank you for reviewing my patch and committing it! I'm glad that I've been able to contribute to such an important project. Thanks, Mateusz Zych On Wed, Jul 9, 2025 at 2:17 PM Jonathan Wakely wrote: > On Fri, 4 Jul 2025 at 13:11, Mateusz Zych wrote: > > > > Hello! > > > > I've updated the Cha

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

> -Original Message- > From: Richard Biener > Sent: Wednesday, July 9, 2025 12:36 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd > Subject: RE: [PATCH 1/3]middle-end: support vec_cbranch_any and > vec_cbranch_all [PR118974] > > On Wed, 9 Jul 2025, Tamar Christina wrote: > >

[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

[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

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

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 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

[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

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 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] libstdc++: Ensure pool resources meet alignment requirements [PR118681]

This breaks several cross compilers: ../../../../../libstdc++-v3/src/c++17/memory_resource.cc: In member function 'virtual void* std::pmr::unsynchronized_pool_resource::do_allocate(std::size_t, std::size_t)': ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:1474:29: error: 'choose_block

[committed] libstdc++: Fix memory_resource.cc bootstrap failure for non-gthreads targets

The new choose_block_size function added in r16-2112-gac2fb60a67d6d1 was defined inside an #ifdef _GLIBCXX_HAS_GTHREADS group, which means that it's not available for single-threaded targets, and so can't be used by unsynchronized_pool_resource. Move it before that preprocessor group so it's always

Re: [PATCH] libstdc++: Ensure pool resources meet alignment requirements [PR118681]

On Wed, 9 Jul 2025 at 10:10, Jonathan Wakely wrote: > > On Wed, 9 Jul 2025 at 09:51, Andreas Schwab wrote: > > > > This breaks several cross compilers: > > > > ../../../../../libstdc++-v3/src/c++17/memory_resource.cc: In member > > function 'virtual void* > > std::pmr::unsynchronized_pool_resou

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

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 inconsistency with -std=gnu++23 (where is_integral_v<__in

[PATCH] testsuite/120093 - fix gcc.dg/vect/pr101145.c

The following changes noinline to noipa to avoid having IPA-CP clones confusing the vectorized loop counting. Tested on x86_64-unknown-linux-gnu, pushed. PR testsuite/120093 * gcc.dg/vect/pr101145.c: Use noipa instead of noinline attribute. --- gcc/testsuite/gcc.dg/vect/p

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

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 for is_floating_point_v to be true for them, but not f

Re: [PATCH] libstdc++: Members missing in std::numeric_limits

On Fri, 4 Jul 2025 at 13:11, Mateusz Zych wrote: > > Hello! > > I've updated the ChangeLog, since I forgot to do it before. Thanks, I've pushed the patch to trunk now. I used a simpler commit message, without the large verbatim quotes from the standard. Thanks again for noticing the problem and

Re: [PATCH] libstdc++: Add smart ptr owner_equals and owner_hash structs and members for P1901R2

Pushed to trunk now - thanks for contributing this! On Tue, 8 Jul 2025 at 18:32, Paul Keir wrote: > > Thanks Jonathan. > > > > From: Jonathan Wakely > Sent: 08 July 2025 1:37 PM > To: Paul Keir > Cc: gcc-patches@gcc.gnu.org; libstd...@gcc.gnu.org > Subjec

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

> > +Operand 0 is a comparison operator. Operand 1 and operand 2 are the > > +first and second operands of the comparison, respectively. Operand 3 > > +is the @code{code_label} to jump to. > > + > > +@cindex @code{cbranch_all@var{mode}4} instruction pattern > > +@item @samp{cbranch_all@var{mode}4

[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 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 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

[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

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

[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

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

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-

[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: [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_

Re: [PATCH] libstdc++: Ensure pool resources meet alignment requirements [PR118681]

On Wed, 9 Jul 2025 at 09:51, Andreas Schwab wrote: > > This breaks several cross compilers: > > ../../../../../libstdc++-v3/src/c++17/memory_resource.cc: In member function > 'virtual void* > std::pmr::unsynchronized_pool_resource::do_allocate(std::size_t, > std::size_t)': > ../../../../../libs

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

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_operand: 1 "register_operand"] + "TARGET_VECTOR"

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

OK if Pan say OK On Wed, Jul 9, 2025 at 4:36 PM 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/au

[PATCH] Avoid accessing STMT_VINFO_VECTYPE

The following fixes up two places we access STMT_VINFO_VECTYPE that's not covered by the fixup in vect_analyze/transform_stmt to set that from SLP_TREE_VECTYPE. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * tree-vect-loop.cc (vectorizable_reduction): Get the outpu

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 v2] testsuite: arm: Update function body for scheduler

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 ran it on trunk to ensure no new failures, but it's not actually need

[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

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 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

[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 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

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 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 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 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

[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

[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

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. > > > >

[committed] s390: Fix vector pattern tests for -m31.

Vectorization of int patterns requires 64bit long type (at least the way the tests are coded). Fix this to only test for successful vectoriation on 64bit targets. Signed-off-by: Juergen Christ gcc/testsuite/ChangeLog: * gcc.target/s390/vector/pattern-avg-1.c: Fix on -m31. * gcc

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

On Wed, 9 Jul 2025, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Wednesday, July 9, 2025 12:36 PM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd > > Subject: RE: [PATCH 1/3]middle-end: support vec_cbranch_any and > > vec_cbranch_all [PR11

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

> > 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_location, at auto-profile.cc:433 I added location and call_location into function instance that are originally set to UNKNOWN_LOCATION and la

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

[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] 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 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] 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: 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: 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

[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] 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 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

[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] 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: 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

  1   2   >