[PATCH] tree-sra: Do not create stores into const aggregates

Hi, this patch fixes (hopefully the) one remaining place where gimple SRA was still creating a load into a const aggregates. It occurs when there was a replacement for a load but that replacement is not type compatible - typically because it was a single field structure. I have used testcases fr

[PATCH] c++: Allow -Wvirtual-move-assign to be more easily ignored

This patch makes it easier to selectively disable -Wvirtual-move-assign by allowing diagnostic pragmas on base class move assignment operators to suppress such warnings. gcc/cp/ChangeLog: * method.cc (synthesized_method_walk): Check whether -Wvirtual-move-assign is enabled at the

Re: [PATCH v2 2/3] libstdc++: Implement C++26 copyable_function [PR119125]

On Mon, 12 May 2025, Tomasz Kamiński wrote: > This patch implements C++26 copyable_function as specified in P2548R6. > It also implements LWG 4255 that adjust move_only_function so constructing > from empty copyable_function, produces empty functor. This falls from > existing checks, after special

Re: [PATCH] fortran: map atand(y, x) to atan2d(y, x) [PR113413]

Hi Yuao, Yuao Ma wrote: Following up on your review comments, I have updated the patch. Thanks - LGTM. Two minor comments, but I have already pushed the commit as r16-602-gb239e9cf98ca92 First: * gfortran.dg/dec_math.f90: Add atand(y, x) testcase. Also for the documentation, the

[PATCH v1 00/10] RISC-V: Combine vec_duplicate + vsub.vv to vsub.vx on GR2VR cost

From: Pan Li This patch would like to introduce the combine of vec_dup + vsub.vv into vsub.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, 15 in test. There will be two cases for the combine: Case 0: | .

[PATCH v1 01/10] RISC-V: Combine vec_duplicate + vsub.vv to vsub.vx on GR2VR cost

From: Pan Li This patch would like to combine the vec_duplicate + vsub.vv to the vsub.vx. From example as below code. The related pattern will depend on the cost of vec_duplicate from GR2VR. Then the late-combine will take action if the cost of GR2VR is zero, and reject the combination if the

[PATCH v1 05/10] RISC-V: Add test for vec_duplicate + vsub.vv combine case 0 with GR2VR cost 1

From: Pan Li Add asm dump check test for vec_duplicate + vsub.vv combine to vsub.vx The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-2-i16.c: Add test cases for vsub vx combine

[PATCH v1 02/10] RISC-V: Rename vx_vadd-* testcase to vx-* for all vx combine [NFC]

From: Pan Li We would like to arrange all vx combine asm check test into one file for better management. Thus, rename vx_vadd-* to vx-*. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx_vadd-1-i16.c: Move to... * gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: ..

[PATCH v1 08/10] RISC-V: Add test for vec_duplicate + vsub.vv combine case 1 with GR2VR cost 1

From: Pan Li Add asm dump check test for vec_duplicate + vsub.vv combine to vsub.vx. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-5-i16.c: Add test cases for vsub vx combin

[PATCH v1 03/10] RISC-V: Adjust vx combine test case to avoid name conflict

From: Pan Li Given we will put all vx combine for int8 in a single file, we need to make sure the generate function for different types and ops has different function name. Thus, refactor the test helper macros for avoiding possible function name conflict. The below test suites are passed for t

[PATCH v1 04/10] RISC-V: Add test for vec_duplicate + vsub.vv combine case 0 with GR2VR cost 0

From: Pan Li Add asm dump check and run test for vec_duplicate + vsub.vv combine to vsub.vx. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add vector sub vx combine

[PATCH v1 09/10] RISC-V: Add test for vec_duplicate + vsub.vv combine case 1 with GR2VR cost 2

From: Pan Li Add asm dump check test for vec_duplicate + vsub.vv combine to vsub.vx. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-6-i16.c: Add test cases for vsub vx combin

[PATCH v1 06/10] RISC-V: Add test for vec_duplicate + vsub.vv combine case 0 with GR2VR cost 15

From: Pan Li Add asm dump check test for vec_duplicate + vsub.vv combine to vsub.vx. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-3-i16.c: Add test cases for vsub vx combin

[PATCH v1 10/10] RISC-V: Reuse test name for vx combine test data [NFC]

From: Pan Li For run test, we have a name like add/sub to indicate the testcase. So we can reuse this to identify the test data instead of a new one. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/a

Re: [PATCH] c++: Add std::to_underlying to the set of stdlib functions that are always folded

On Tue, 13 May 2025 at 23:42, Ville Voutilainen wrote: > > > It seems to me that this > > > sanity check is checking that it's a cast between > > > references for the other ones, and that's just unsuitable for > > > to_underlying. I would suggest just removing that sanity > > > check and trusting

[PATCH v1 07/10] RISC-V: Add test for vec_duplicate + vsub.vv combine case 1 with GR2VR cost 0

From: Pan Li Add asm dump check test for vec_duplicate + vsub.vv combine to vsub.vx. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add test cases for vsub vx combin

PING – Re: [Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR120225]

Admittedly, this *PING* is rather early – but as more trigonometric functions changes are coming, I think it would be useful to agree that this is a good approach. And the patch is simple. BTW: For the infrastructure/download update, I have filed https://gcc.gnu.org/PR120237 Next would be the s

Re: [PATCH v21 1/3] c: Add _Countof operator

On Tue, 13 May 2025 at 11:13, Alejandro Colomar wrote: > > Hi Jonathan, > > On Tue, May 13, 2025 at 10:39:21AM +0100, Jonathan Wakely wrote: > > On Mon, 12 May 2025 at 23:15, Alejandro Colomar wrote: > > >

Re: [PATCH][RFC] Add vector_costs::add_vector_cost vector stmt grouping hook

On Tue, 13 May 2025, Richard Sandiford wrote: > Richard Biener writes: > > The following refactors the vectorizer vector_costs target API > > to add a new vector_costs::add_vector_cost entry which groups > > all individual sub-stmts we create per "vector stmt", aka SLP > > node. This allows for

Re: [PATCH] libfortran: Fix up _gfortran_{, m, s}findloc2_s{1, 4} [PR120196]

Hi Jakub, Jakub Jelinek wrote: As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many times in the back case if nothing is found. For !back, the loops are for (i = 1; i <= extent; i++) so i is in the body [1, extent] if nothing is found, but for back it is for (i = extent; i >

Re: [PATCH 2/4][c-frontend]: implement pragma unroll n for C [PR116140]

On Tue, 13 May 2025, Tamar Christina wrote: > To know whether this should be possible to do or not this proposes an > extension > to the pragma GCC unroll with an argument to indicate if we can override the > value or not. This patch is missing updates to the documentation for that pragma. --

Re: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

On Tue, 13 May 2025, Eric Botcazou wrote: > > In PR116140 it was brought up that adding pragma GCC unroll in std::find > > makes it so that you can't use a larger unroll factor if you wanted to. > > This is because the value can't be overriden by the other unrolling flags > > such as -funroll-loo

Re: [PATCH 1/2]middle-end: Add new parameter to scale scalar loop costing in vectorizer

On Tue, 13 May 2025, Tamar Christina wrote: > Hi All, > > This patch adds a new param vect-scalar-cost-multiplier to scale the scalar > costing during vectorization. If the cost is set high enough and when using > the dynamic cost model it has the effect of effectively disabling the > costing vs

Re: [PATCH] libfortran: Fix up _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} [PR120191]

Jakub Jelinek wrote: There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the following testcase shows. The functions return but then crash in the caller. Seems that is because buffer overflows, I believe those functions for if (mask == NULL || *mask) condition being false are sup

RE: [PATCH 2/4][c-frontend]: implement pragma unroll n for C [PR116140]

> -Original Message- > From: Joseph Myers > Sent: Tuesday, May 13, 2025 12:35 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd > Subject: Re: [PATCH 2/4][c-frontend]: implement pragma unroll n > for C [PR116140] > > On Tue, 13 May 2025, Tamar Christina wrote: > > > To know w

[PATCH 4/5] c++, coroutines: Use decltype(auto) for the g_r_o.

The revised wording for coroutines, uses decltype(auto) for the type of the get return object, which preserves references. The test is expected to fail, since it attempts to initialize the return object from an object that has already been destroyed. gcc/cp/ChangeLog: * coroutines.cc

[PATCH 5/5] c++, coroutines: Clean up the ramp cleanups.

This replaces the cleanup try-catch block in the ramp with a series of eh-only cleanup statements. gcc/cp/ChangeLog: * coroutines.cc (cp_coroutine_transform::build_ramp_function): Replace ramp cleanup try-catch block with eh-only cleanup statements. Signed-off-by: Iain Sa

Re: [PATCH v1] contrib/: Add support for Link: tags

On 5/12/25 6:03 PM, Alejandro Colomar wrote: On Mon, May 12, 2025 at 05:42:55PM +0100, Jonathan Wakely wrote: On Mon, 12 May 2025 at 17:34, Jonathan Wakely wrote: On Mon, 12 May 2025 at 16:46, Alejandro Colomar wrote: contrib/ChangeLog: * gcc-changelog/git_commit.py (GitCommit):

Re: [PATCH 1/5] c++: Set the outer brace marker for missed cases.

On 5/13/25 10:30 AM, Iain Sandoe wrote: In some cases, a function might be declared as FUNCTION_NEEDS_BODY_BLOCK but all the content is contained within that block. However, poplevel is currently assuming that such cases would always contain subblocks. In the case that we do have a body block,

Re: [PATCH v1] contrib/: Add support for Link: tags

On Tue, 13 May 2025 at 15:35, Jason Merrill wrote: > > On 5/12/25 6:03 PM, Alejandro Colomar wrote: > > On Mon, May 12, 2025 at 05:42:55PM +0100, Jonathan Wakely wrote: > >> On Mon, 12 May 2025 at 17:34, Jonathan Wakely wrote: > >>> On Mon, 12 May 2025 at 16:46, Alejandro Colomar wrote: > >

[PATCH 1/3] Remove non-SLP path from vectorizable_induction

--- gcc/tree-vect-loop.cc | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc index fe6f3cf188e..36087d130d5 100644 --- a/gcc/tree-vect-loop.cc +++ b/gcc/tree-vect-loop.cc @@ -9723,7 +9723,7 @@ vectorizable_nonlinear_

RE: [PATCH 1/2]middle-end: Apply loop->unroll directly in vectorizer

> -Original Message- > From: Richard Biener > Sent: Tuesday, May 13, 2025 1:59 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd > Subject: Re: [PATCH 1/2]middle-end: Apply loop->unroll directly in vectorizer > > On Tue, 13 May 2025, Tamar Christina wrote: > > > Hi All, > > >

[PATCH 2/3] Remove non-SLP path from vectorizable_induction

--- gcc/tree-vect-loop.cc | 1007 ++--- 1 file changed, 342 insertions(+), 665 deletions(-) diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc index 36087d130d5..3ab2f4d52c7 100644 --- a/gcc/tree-vect-loop.cc +++ b/gcc/tree-vect-loop.cc @@ -9723,7 +9723

[PATCH 3/3] Remove non-SLP path from vectorizable_induction

This removes the non-SLP path from vectorizable_induction. Bootstrapped and tested on x86_64-unknown-linux-gnu, squashed and pushed. * tree-vect-loop.cc (vectorizable_nonlinear_induction): Remove non-SLP path, use SLP_TREE_VECTYPE. (vectorizable_induction): Likewise. Drop

[PATCH 3/5] c++, coroutines: Address CWG2563 return value init [PR119916].

This addresses the clarification that, when the get_return_object is of a different type from the ramp return, any necessary conversions should be performed on the return expression (so that they typically occur after the function body has started execution). PR c++/119916 gcc/cp/ChangeLo

[PATCH 1/5] c++: Set the outer brace marker for missed cases.

In some cases, a function might be declared as FUNCTION_NEEDS_BODY_BLOCK but all the content is contained within that block. However, poplevel is currently assuming that such cases would always contain subblocks. In the case that we do have a body block, but there are no subblocks then st the out

[PATCH] i386: Quote user-defined symbols in assembly in Intel syntax

Hello, Attached is a patch for PR 53929, but is also required by PR 80881. With native Windows thread-local storage (TLS) on master, GCC may generate assembly like: mov eax, [rdx + my_variable@secrel32] GAS doesn't parse this correctly. Since `@` is a valid character in symbols of `__fas

Re: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

On Tue, 13 May 2025, Jakub Jelinek wrote: > On Tue, May 13, 2025 at 10:40:16AM +, Tamar Christina wrote: > > That's true. The names are already optional, I can just drop the > > "requested" > > all together. > > > > I'll give it a few to give others a chance to commit and I'll respin > > d

Re: [PATCH 1/2]middle-end: Apply loop->unroll directly in vectorizer

On Tue, 13 May 2025, Tamar Christina wrote: > Hi All, > > Consider the loop > > void f1 (int *restrict a, int n) > { > #pragma GCC unroll 4 requested > for (int i = 0; i < n; i++) > a[i] *= 2; > } > > Which today is vectorized and then unrolled 3x by the RTL unroller due to the > use of t

Re: [PATCH v2 1/2] Extend vect_recog_cond_expr_convert_pattern to handle floating point type.

On Tue, May 13, 2025 at 5:23 AM liuhongt wrote: > > Updated in V2 > > > > Can you instead of mangling in float support use separate (match like > > for the below cases? > I tried, but reported duplicated defination since they share same pattern > like > > (cond (simple_comparison@6 @0 @1) (conver

Re: [PATCH v2 2/2] Extend vect_recog_cond_expr_convert_pattern to handle REAL_CST

On Tue, May 13, 2025 at 5:22 AM liuhongt wrote: > > REAL_CST is handled if it can be represented in different floating > point types without loss of precision or under fast math. > > gcc/ChangeLog: > > PR tree-optimization/103771 > * match.pd (cond_expr_convert_p): Extend the match

Re: [PATCH] verifier: Fix up PAREN_EXPR verification [PR118868]

On Tue, May 13, 2025 at 9:21 AM Andrew Pinski wrote: > > The verification added in r12-1608-g2f1686ff70b25f, was incorrect > for PAREN_EXPR, pointer types should be valid for PAREN_EXPR. > Also for PAREN_EXPR, aggregate types don't make sense (currently > they ICE much earlier in the gimplifier ra

Re: [PATCH] x86: Enable separate shrink wrapping

On Tue, May 13, 2025 at 12:36 PM Uros Bizjak wrote: > > On Tue, May 13, 2025 at 8:15 AM Cui, Lili wrote: > > > > From: Lili Cui > > > > Hi, > > > > This patch is to enale separate shrink wrapping for x86. > > > > Bootstrapped & regtested on x86-64-pc-linux-gnu. > > > > Ok for trunk? > > Unfortun

RE: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

> -Original Message- > From: Jakub Jelinek > Sent: Tuesday, May 13, 2025 11:49 AM > To: Tamar Christina > Cc: Jonathan Wakely ; gcc-patches@gcc.gnu.org; nd > ; rguent...@suse.de > Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n > [PR116140] > > On Tue, May 13, 2025 at 10:40

Re: [PATCH] libfortran: Fix up _gfortran_s{max,min}loc2_{4,8,16}_s{1,4} [PR120191]

First is slightly confusing as there are three patches for PR120191. In particular, two which look almost identical - one for loc2 (this one) and one for loc1 (the one sent one our later). Jakub pointed out that the remarks after "ok for trunk?" for this patch are obsoleted by the follow up patch

RE: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

> -Original Message- > From: Richard Biener > Sent: Tuesday, May 13, 2025 12:44 PM > To: Eric Botcazou > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd > > Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n > [PR116140] > > On Tue, 13 May 2025, Eric Botcazou wrote: > > >

[PATCH] verifier: Fix up PAREN_EXPR verification [PR118868]

The verification added in r12-1608-g2f1686ff70b25f, was incorrect for PAREN_EXPR, pointer types should be valid for PAREN_EXPR. Also for PAREN_EXPR, aggregate types don't make sense (currently they ICE much earlier in the gimplifier rather than error message) so we should disallow them here too. B

[PATCH v3] RISC-V: Add augmented hypervisor series extensions.

The augmented hypervisor series extensions 'sha'[1] is a new profile-defined extension series that captures the full set of features that are mandated to be supported along with the 'H' extension. [1] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23s64-profile Versi

Re: [PATCH v1] contrib/: Add support for Link: tags

Hi Jonathan, On Tue, May 13, 2025 at 10:50:23AM +0100, Jonathan Wakely wrote: > Fair enough, I have no objection to adding Link: support to the > git_commit.py script. (We don't really have anybody who is the owner > of those scripts now, so I think you need a global reviewer to approve > it.) Th

Re: [PATCH 4/4][libstdc++] use pragma GCC 4 preferred for std::find [PR116140]

On 13/05/25 10:41 +0100, Tamar Christina wrote: Hi All, In PR116140 it was brought up that adding pragma GCC unroll in std::find makes it so that you can't use a larger unroll factor if you wanted to. This is because the value can't be overriden by the other unrolling flags such as -funroll-loo

RE: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

> -Original Message- > From: Jonathan Wakely > Sent: Tuesday, May 13, 2025 11:01 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de > Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n > [PR116140] > > On 13/05/25 10:39 +0100, Tamar Christina wrote:

Re: [PATCH v5 05/10] libstdc++: Implement layout_left from mdspan.

On 5/12/25 6:02 PM, Tomasz Kaminski wrote: Thank you for all the work that you have done by doing the two implementations and extensive test cases. I wanted to respond to a few points that I think we may want to consider to be bugs in specification, and report them as bugs in standard. (Would y

Re: [PATCH v21 1/3] c: Add _Countof operator

Hi Jonathan, On Tue, May 13, 2025 at 10:39:21AM +0100, Jonathan Wakely wrote: > On Mon, 12 May 2025 at 23:15, Alejandro Colomar wrote: > > > > > > Acked-by: may also be use

[PATCH][RFC] Add vector_costs::add_vector_cost vector stmt grouping hook

The following refactors the vectorizer vector_costs target API to add a new vector_costs::add_vector_cost entry which groups all individual sub-stmts we create per "vector stmt", aka SLP node. This allows for the targets to more easily match on complex cases like emulated gather/scatter or even ju

[PATCH 1/2]middle-end: Add new parameter to scale scalar loop costing in vectorizer

Hi All, This patch adds a new param vect-scalar-cost-multiplier to scale the scalar costing during vectorization. If the cost is set high enough and when using the dynamic cost model it has the effect of effectively disabling the costing vs scalar and assumes all vectorization to be profitable.

[PATCH 2/2]AArch64: propose -mmax-vectorization as an option to override vector costing

Hi All, With the middle-end providing a way to make vectorization more profitable by scaling vect-scalar-cost-multiplier this makes a more user friendly option to make it easier to use. I propose making it an actual -m option that we document and retain vs using the parameter name. In the future

Re: [PATCH][RFC] Add vector_costs::add_vector_cost vector stmt grouping hook

Richard Biener writes: > The following refactors the vectorizer vector_costs target API > to add a new vector_costs::add_vector_cost entry which groups > all individual sub-stmts we create per "vector stmt", aka SLP > node. This allows for the targets to more easily match on > complex cases like

Ping^2: [PATCH v4 00/20] FMV refactor and ACLE compliance.

Hi all, Ping for this main patch series. Alfie On 15/04/2025 11:31, Alfie Richards wrote: Hi all, Another update to this series. This patch changes the version info structure to be sorted by priority. This allows easier reasoning for optimisations and prevents having to calculate the priorit

Re: [PATCH] fortran, v2: Fix up minloc/maxloc lowering [PR120191]

Jakub Jelinek wrote: Here is an updated patch including your incremental changes. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? LGTM. Thanks for the patch – and sorry for the delayed review. Tobias Trying to write a testcase I've run into further issues but seems they

Re: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

On 13/05/25 10:39 +0100, Tamar Christina wrote: Hi All, In PR116140 it was brought up that adding pragma GCC unroll in std::find makes it so that you can't use a larger unroll factor if you wanted to. This is because the value can't be overriden by the other unrolling flags such as -funroll-loo

[PATCH 2/5] c++, coroutines: Allow NVRO in more cases for ramp functions.

The constraints of the c++ coroutines specification require the ramp to construct a return object early in the function. This will be returned at some later time. To meet the requirements of copy-elision, we need to ensure NVRO for these objects, even when they are non-copyable or non-movable. S

Re: [PATCH v1] contrib/: Add support for Link: tags

Hi Jason, On Tue, May 13, 2025 at 10:35:00AM -0400, Jason Merrill wrote: > > > It seems to be one of the more common trailers used in the linux > > > kernel [1], > > Hmm, I don't see it in that list. But it is described in > https://docs.kernel.org/process/submitting-patches.html It was mentio

Re: [PATCH 2/5] c++, coroutines: Allow NVRO in more cases for ramp functions.

On 5/13/25 10:30 AM, Iain Sandoe wrote: The constraints of the c++ coroutines specification require the ramp to construct a return object early in the function. This will be returned at some later time. To meet the requirements of copy-elision, we need to ensure NVRO for these objects, even whe

[PATCH GCC-14.3] c++, coroutines: Fix handling of early exceptions [PR113773].

This could not be done as a cherry-pick from the trunk resolution. Tested on x86_64-darwin, powerpc64le linux sparc9 solaris, OK for 14.3 ? thanks Iain --- 8< --- This is a GCC-14 version of the same strategy as used on trunk, but with the more wide-ranging code cleanups elided. PR c++/1

[PATCH 3/4][c++-frontend]: implement pragma unroll n for C++ [PR116140]

Hi All, In PR116140 it was brought up that adding pragma GCC unroll in std::find makes it so that you can't use a larger unroll factor if you wanted to. This is because the value can't be overriden by the other unrolling flags such as -funroll-loops. To know whether this should be possible to do

[PATCH 4/4][libstdc++] use pragma GCC 4 preferred for std::find [PR116140]

Hi All, In PR116140 it was brought up that adding pragma GCC unroll in std::find makes it so that you can't use a larger unroll factor if you wanted to. This is because the value can't be overriden by the other unrolling flags such as -funroll-loops. To know whether this should be possible to do

[PATCH 1/2]middle-end: Apply loop->unroll directly in vectorizer

Hi All, Consider the loop void f1 (int *restrict a, int n) { #pragma GCC unroll 4 requested for (int i = 0; i < n; i++) a[i] *= 2; } Which today is vectorized and then unrolled 3x by the RTL unroller due to the use of the pragma. This is unfortunate because the pragma was intended for the

[PATCH 2/2]AArch64: Use vectorizer initial unrolling as default

Hi All, The vectorizer now tries to maintain the target VF that a user wanted through uncreasing the unroll factor if the user used pragma GCC unroll and we've vectorized the loop. This change makes the AArch64 backend honor this initial value being set by the vectorizer. Consider the loop void

Re: [PATCH v21 1/3] c: Add _Countof operator

On Mon, 12 May 2025 at 23:15, Alejandro Colomar wrote: > > Hi Jonathan, > > On Mon, May 12, 2025 at 06:11:18PM +0100, Jonathan Wakely wrote: > > On 12/05/25 17:53 +0200, Alejandro Colomar wrote: > > > Suggested-by: Xavier Del Campo Romero > > > Co-authored-by: Martin Uecker > > > Acked-by: "Jame

[PATCH 1/4]middle-end: document pragma unroll n [PR116140]

Hi All, In PR116140 it was brought up that adding pragma GCC unroll in std::find makes it so that you can't use a larger unroll factor if you wanted to. This is because the value can't be overriden by the other unrolling flags such as -funroll-loops. To know whether this should be possible to do

Re: [PATCH v1] contrib/: Add support for Link: tags

On Mon, 12 May 2025 at 23:03, Alejandro Colomar wrote: > > Hi Jonathan, > > On Mon, May 12, 2025 at 05:42:55PM +0100, Jonathan Wakely wrote: > > On Mon, 12 May 2025 at 17:34, Jonathan Wakely wrote: > > > > > > On Mon, 12 May 2025 at 16:46, Alejandro Colomar wrote: > > > > > > > > contrib/ChangeL

[PATCH 2/4][c-frontend]: implement pragma unroll n for C [PR116140]

Hi All, In PR116140 it was brought up that adding pragma GCC unroll in std::find makes it so that you can't use a larger unroll factor if you wanted to. This is because the value can't be overriden by the other unrolling flags such as -funroll-loops. To know whether this should be possible to do

Re: [PATCH 1/3] cfgexpand: Reverse the order of going through the update_cache_list queue.

On Tue, May 13, 2025 at 12:48 AM Andrew Pinski wrote: > > This is a small optimization, the reversed order of the walk of > update_cache_list queue. > The queue is pushed in Pre-order/NLR, reversing the order will reduce how > many times we > need to go through the loop as we update the nodes wh

Re: [PATCH 2/3] cfgexpand: Update cache during the original DFS walk

On Tue, May 13, 2025 at 12:47 AM Andrew Pinski wrote: > > This is a small optimization which can improve how many times are need > through the update loop. > It can reduce the number of times in the update loop by maybe 1 times. > > Bootstrapped and tested on x86_64-linux-gnu. OK. > gcc/ChangeL

Ping^3: [PATCH v4] get source line for diagnostic from preprocessed file [PR preprocessor/79106]

Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676875.html

Re: [PATCH] x86: Enable separate shrink wrapping

On Tue, May 13, 2025 at 8:15 AM Cui, Lili wrote: > > From: Lili Cui > > Hi, > > This patch is to enale separate shrink wrapping for x86. > > Bootstrapped & regtested on x86-64-pc-linux-gnu. > > Ok for trunk? > > > This commit implements the target macros (TARGET_SHRINK_WRAP_*) that > enable separ

RE: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

> -Original Message- > From: Richard Biener > Sent: Tuesday, May 13, 2025 1:36 PM > To: Jakub Jelinek > Cc: Tamar Christina ; Jonathan Wakely > ; gcc-patches@gcc.gnu.org; nd > Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n > [PR116140] > > On Tue, 13 May 2025, Jakub Jelin

[to-be-committed][RISC-V][PR target/120223] Don't use bset/binv for XTHEADBS

Thead has the XTHEADBB extension which has a lot of overlap with Zbb. I made the incorrect assumption that XTHEADBS would largely be like Zbs when generalizing Shreya's work. As a result we can't use the operation synthesis code for IOR/XOR because we don't have binv/bset like capabilities.

[PATCH 3/4] Revert change to pass SLP node to cost hook for scalar_{load,store}

The following reverts the change done to vectorizable_store/load to always pass the SLP node to the costing hook, in particular for the cases of costing scalar loads and stores. * tree-vect-stmts.cc (vectorizable_store): For scalar_store costing only pass in stmt_info. (vec

[PATCH 1/4] This transitions vect_model_simple_cost to SLP only

As part of the vector cost API cleanup this transitions vect_model_simple_cost to only record costs with SLP node. For this to work the patch adds an overload to record_stmt_cost only passing in the SLP node. The vect_prologue_cost_for_slp adjustment is one spot that needs an eye with regard to re

[Patch, RFC] git_update_version.py: Support vendor-branch version bumps (was: [RFC] Enable automatic ChangeLog updates on devel/omp/gcc-15 branch)

Hi Sandra, hello world, Sandra Loosemore wrote: I have created the devel/omp/gcc-15 (aka "OG15") branch, ... For previous branches we'd been using ChangeLog.omp files paralleling the normal ChangeLog files, that were updated manually and committed with the corresponding patch.  In preparing

[PATCH] libfortran: Fix up _gfortran_{, m, s}findloc2_s{1, 4} [PR120196]

Hi! As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many times in the back case if nothing is found. For !back, the loops are for (i = 1; i <= extent; i++) so i is in the body [1, extent] if nothing is found, but for back it is for (i = extent; i >= 0; i--) so i is in the body

[PATCH 4/4] Remove the mixed stmt_vec_info/SLP node record_stmt_cost overload

The following changes the record_stmt_cost calls in vectorizable_load/store to only pass the SLP node when costing vector stmts. For now we'll still pass the stmt_vec_info, determined from SLP_TREE_REPRESENTATIVE, so this merely cleans up the API. Bootstrap and regtest running on x86_64-unknown-l

[PATCH 2/4] Use vectype from SLP node for vect_get_{load, store}_cost if possible

The vect_get_{load,store}_cost API is used from both vectorizable_* where we've done SLP analysis and from alignment peeling analysis with is done before this and thus only stmt_vec_infos are available. The following patch makes sure we pick the vector type relevant for costing from the SLP node wh

Re: [PATCH v2] gimple-fold: Don't replace `tmp = FP0 CMP FP1; if (tmp != 0)` over and over again when comparison can throw

On Mon, May 12, 2025 at 10:52 PM Andrew Pinski wrote: > > with -ftrapping-math -fnon-call-exceptions and: > ``` > tmp = FP0 CMP FP1; > > if (tmp != 0) ... > ``` > a call fold_stmt on the GIMPLE_COND will replace the above with > a new tmp each time and we even lose the eh informatin on the > previ

Re: [PATCH] gimple-fold: Don't replace `tmp = FP0 CMP FP1; if (tmp != 0)` over and over again when comparison can throw

On Mon, May 12, 2025 at 7:16 PM Andrew Pinski wrote: > > On Mon, May 12, 2025 at 3:51 AM Richard Biener > wrote: > > > > On Sat, May 10, 2025 at 3:19 AM Andrew Pinski > > wrote: > > > > > > with -ftrapping-math -fnon-call-exceptions and: > > > ``` > > > tmp = FP0 CMP FP1; > > > > > > if (tmp !=

RE: [PATCH] Cleanup internal vectorizer costing API

On Mon, 12 May 2025, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Monday, May 12, 2025 1:46 PM > > To: gcc-patches@gcc.gnu.org > > Cc: Tamar Christina ; RISC-V CI > c...@rivosinc.com> > > Subject: [PATCH] Cleanup internal vectorizer costing API > > >

[PATCH] This transitions vect_model_simple_cost to SLP only

As part of the vector cost API cleanup this transitions vect_model_simple_cost to only record costs with SLP node. For this to work the patch adds an overload to record_stmt_cost only passing in the SLP node. The vect_prologue_cost_for_slp adjustment is one spot that needs an eye with regard to re

Re: [PATCH] gimple-fold: Canonicalize _Bool == 0 and _Bool != 1

On Mon, May 12, 2025 at 7:32 PM Andrew Pinski wrote: > > On Mon, May 12, 2025 at 3:56 AM Richard Biener > wrote: > > > > On Sat, May 10, 2025 at 3:13 AM Andrew Pinski > > wrote: > > > > > > This move this canonicalization from forwprop > > > (forward_propagate_into_gimple_cond) > > > to gimple

Re: [PATCH] libgcobol: Allow for lack of LOG_PERROR

Hi Robert, > If you have a patch that works for you, by all means, push it. done now, thanks. > As for the philosophy and reasons for logging...I have to defer to Jim to > come up with a cogent response. I personally wouldn't have bothered with > any logging code. There may be some delays in h

Re: [PATCH] x86: Enable separate shrink wrapping

On Tue, May 13, 2025 at 8:15 AM Cui, Lili wrote: > > From: Lili Cui > > Hi, > > This patch is to enale separate shrink wrapping for x86. > > Bootstrapped & regtested on x86-64-pc-linux-gnu. > > Ok for trunk? Unfortunately, the patched compiler fails to boot the latest linux kernel. Uros. Uro

Re: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

On Tue, 13 May 2025 at 11:26, Tamar Christina wrote: > > > -Original Message- > > From: Jonathan Wakely > > Sent: Tuesday, May 13, 2025 11:01 AM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de > > Subject: Re: [PATCH 1/4]middle-end: document pragma unroll

Re: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

> In PR116140 it was brought up that adding pragma GCC unroll in std::find > makes it so that you can't use a larger unroll factor if you wanted to. > This is because the value can't be overriden by the other unrolling flags > such as -funroll-loops. What about letting -funroll-loops either augme

Re: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

On Tue, May 13, 2025 at 10:40:16AM +, Tamar Christina wrote: > That's true. The names are already optional, I can just drop the "requested" > all together. > > I'll give it a few to give others a chance to commit and I'll respin dropping > "requested" Is the intended behavior of the "weak"

RE: [PATCH 1/4]middle-end: document pragma unroll n [PR116140]

> -Original Message- > From: Jonathan Wakely > Sent: Tuesday, May 13, 2025 11:34 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de > Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n > [PR116140] > > On Tue, 13 May 2025 at 11:26, Tamar Christina

RE: [PATCH 2/4][c-frontend]: implement pragma unroll n for C [PR116140]

On Tue, 13 May 2025, Tamar Christina wrote: > > -Original Message- > > From: Joseph Myers > > Sent: Tuesday, May 13, 2025 12:35 PM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd > > Subject: Re: [PATCH 2/4][c-frontend]: implement pragma unroll n > > for C [PR116140] > > >

Re: [PATCH 4/6] RISC-V: frm/mode-switch: TARGET_MODE_AFTER not needed for frm switching

On 5/10/25 07:27, Jeff Law wrote: > > On 5/9/25 2:27 PM, Vineet Gupta wrote: >> Stumbled upon this when trying to wholesale rewrite frm switching code >> and seeing what pieces needed to be retained from current implementation. >> >> My interpretation of how this hook worked, for the following c

[PATCH 0/5] Address proposed CWG2563 resolution (BZ 119916).

The proposed resolution to CWG 2563 clarifies that any conversions to be applied between the result of promise.get_return_object() and the ramp return object should be carried out as part of the return expression (rather than at the time promise.get_return_object() is evaluated). It also makes cle

[PATCH 1/2] forwprop: Fix looping after fold_stmt and some forwprop local folds happen

r10-2587-gcc19f80ceb27cc added a loop over the current statment if there was a change. Except in some cases it turns out changed will turn from true to false because instead of doing |= after the fold_stmt, there was an just an `=`. This fixes that and now we loop even if fold_stmt changed the stat

[PATCH v4 3/3][C FE] Use the counted_by attribute of pointers in array bound checker.

Current array bound checker only instruments ARRAY_REF, and the INDEX information is the 2nd operand of the ARRAY_REF. When extending the array bound checker to pointer references with counted_by attributes, the hardest part is to get the INDEX of the corresponding array ref from the offset comput

  1   2   >