Re: [PATCH] libstdc++: Preserve the argument type in basic_format_args [PR119246]

On Tue, May 13, 2025 at 10:04 PM Jonathan Wakely wrote: > On 30/04/25 13:23 +0200, Tomasz Kamiński wrote: > >This commits adjust the way how the arguments are stored in the _Arg_value > >(and thus basic_format_args), by preserving the types of fixed width > >floating-point types, that were previo

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

Hi Tobias, > 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. Patch is OK to push. FX

Re: [patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

Hi Thomas, Same remark as for PR120107! LGTM for both branches. Thanks Paul On Tue, 13 May 2025 at 21:30, Thomas Koenig wrote: > Hello world, > > this fixes the other regression which crept in with gfortran. > Again, regression-tested, plus the local testing script is > attached. > > Ok for

RE: [PATCH 0/5] Remove -mavx10.1-256/512 and -mno-evex512

> From: Haochen Jiang > Sent: Wednesday, May 14, 2025 2:17 PM > > Hi all, > > As mentioned in GCC 15, we will remove -mavx10.1-256/512 and -mno- > evex512 options in GCC 16. Also we will do some clean up in code for all the > size happening all together. > > The first patch of the patch set rem

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

> Am 13.05.2025 um 23:24 schrieb Martin Jambor : > > 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 - typicall

Re: [patch, Fortran] Fix 15/16 regression when non-interoperable types were dumped

Hi Thomas, I don't think that anybody else has been up to the job of hacking dejagnu to test patches to dump-parse-tree.cc :-) I think that the patch verges on the 'obvious' and is good for both 15-branch and mainline. Thanks for the patch. Paul On Tue, 13 May 2025 at 21:15, Thomas Koenig wr

[PATCH 0/5] Remove -mavx10.1-256/512 and -mno-evex512

Hi all, As mentioned in GCC 15, we will remove -mavx10.1-256/512 and -mno-evex512 options in GCC 16. Also we will do some clean up in code for all the size happening all together. The first patch of the patch set removes those options, while the following four is refactoring and cleaning up for t

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

> -Original Message- > From: Richard Biener > Sent: Tuesday, May 13, 2025 12:08 PM > To: Richard Sandiford > Cc: gcc-patches@gcc.gnu.org; Tamar Christina > Subject: Re: [PATCH][RFC] Add vector_costs::add_vector_cost vector stmt > grouping hook > > On Tue, 13 May 2025, Richard Sandiford

[PATCH 2/5] i386: Remove duplicate iterators in md

There are several iterators no longer needed in md files since after refactor in AVX10, they could directly use legacy AVX512 ones. Remove those duplicate iterators. gcc/ChangeLog: * config/i386/sse.md (VF1_VF2_AVX10_2): Removed. (VF2_AVX10_2): Ditto. (VI1248_AVX10_2): Dit

Re: [PATCH] x86: Add preserve_none and update no_caller_saved_registers attributes

On Fri, Apr 18, 2025 at 7:10 PM H.J. Lu wrote: > > Add preserve_none attribute which is similar to no_callee_saved_registers > attribute, except on x86-64, r12, r13, r14, r15, rdi and rsi registers are Could you split preserve_none into a separate patch, It looks like it's different from clang's p

[PATCH v3] Extend vect_recog_cond_expr_convert_pattern to handle REAL_CST

So it won't do the unsafe truncation for double(1.001) to float(1.0) since there's precision loss. It's guarded by testcase pr103771-6.c Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? REAL_CST is handled if it can be represented in different floating point typ

Re: [PATCH] ctf: use CTF_FP_LDOUBLE encoding for 128-bit floats

On 2025-05-01 2:56 p.m., Bruce McCulloch wrote: Currently, gen_ctf_base_type will obtain the bit_size of a given DWARF DIE based on the system GCC is compiling for. For DIEs with a DW_ATE_float encoding, this is used to determine whether to classify a given DIE as a single, double, or long double

[PATCH] [rs6000] add os-missing-powerpc64.h for powerpc-elf

On Apr 16, 2025, Alexandre Oliva wrote: > But I acknowledge that it's a bit of a risky proposition; I suppose it > would be more conservative to disable it uniformly on all targets, and > only enable it with -m32 when explicitly requested. I.e., make > OS_MISSING_POWERPC64 the rule rather than t

[PATCH][GCC15/14/13/12] dwarf2out: Propagate dtprel into the .debug_addr table in resolve_addr_in_expr

For a debugger to display statically-allocated[0] TLS variables the compiler must communicate information[1] that can be used in conjunction with knowledge of the runtime enviroment[2] to calculate a location for the variable for each thread. That need gives rise to dw_loc_dtprel in dwarf2out, a fl

Re: [AUTOFDO][AARCH64] Add support for profilebootstrap

Adding Eugene and Andi to CC as Sam suggested. > On 13 May 2025, at 12:57 am, Richard Sandiford > wrote: > > External email: Use caution opening links or attachments > > > Kugan Vivekanandarajah writes: >> diff --git a/configure.ac b/configure.ac >> index 730db3c1402..701284e38f2 100644 >> ---

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

On 5/13/25 5:18 PM, Owen Avery wrote: 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. Pushed, thanks! gcc/cp/ChangeLog: * method.cc (synthesized_method_walk): Che

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

On 5/13/25 7:15 PM, Ville Voutilainen wrote: 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

Re: [PATCH] Update libbid according to the latest Intel Decimal Floating-Point Math Library.

On Wed, May 14, 2025 at 9:22 AM liuhongt wrote: > > The Intel Decimal Floating-Point Math Library is available as open-source on > Netlib[1]. > > [1] https://www.netlib.org/misc/intel/ > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ready push to trunk. > > libgcc/config/libbid/Ch

[PATCH v3] Consider frequency in cost estimation when converting scalar to vector.

Update in V3 > > > +  cost_sse_integer = 0; > > > +  weighted_cost_sse_integer = 0 ; > Extra space here. Changed. > > > +       : ix86_size_cost.sse_to_integer; > > Please be sure to not revert the changes from my patch adding >   COSTS_N_INSNS (...) / 2 > here and some other places. Yes, keep the

[PATCH] Update libbid according to the latest Intel Decimal Floating-Point Math Library.

The Intel Decimal Floating-Point Math Library is available as open-source on Netlib[1]. [1] https://www.netlib.org/misc/intel/ Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready push to trunk. libgcc/config/libbid/ChangeLog: * bid128_string.c (MIN_DIGITS): New macro.

[PATCH 3/3] gimple: Move canonicalization of bool==0 and bool!=1 to cleanupcfg

This moves the canonicalization of `bool==0` and `bool!=1` from forwprop to cleanupcfg. We will still need to call it from forwprop so we don't need to call forwprop a few times to fp comparisons in some cases (forwprop-16.c was added originally for this code even). This is the first step in remov

[PATCH 2/3] gimple: Add assert for code being a comparison in gimple_cond_set_code

We have code later on that verifies the code is a comparison. So let's try to catch it earlier. So it is easier to debug where the incorrect code gets set. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * gimple.h (gimple_cond_set_code): Add assert of the code being

[PATCH 1/3] forwprop: Change an if into an assert

Since the merge of the tuples branch (r0-88576-g726a989a8b74bf), the if: ``` if (TREE_CODE_CLASS (gimple_cond_code (stmt)) != tcc_comparison) ``` Will always be false so let's change it into an assert. gcc/ChangeLog: * tree-ssa-forwprop.cc (forward_propagate_into_gimple_cond): Assert

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

[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

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

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

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

[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 3/3] libstdc++: Renamed bits/move_only_function.h to bits/funcwrap.h [PR119125]

On Mon, 12 May 2025, Tomasz Kamiński wrote: > The file now includes copyable_function in addition to > move_only_function. > > PR libstdc++/119125 > > libstdc++-v3/ChangeLog: > * include/bits/move_only_function.h: Move to... > * include/bits/funcwrap.h: ...here. > * doc/d

Re: [PATCH v2 1/3] libstdc++: Avoid double indirection in move_only_function when possible [PR119125]

On Mon, 12 May 2025, Tomasz Kamiński wrote: > Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the > generic > move_only_function(_Fn&&) constructor, such that when _Fn refers to selected > move_only_function instantiations, the ownership of the target object is > direclt

[PATCH v4 2/3][C][__bdos] Convert a pointer reference with counted_by attribute to .ACCESS_WITH_SIZE and use it in builtinin-object-size.

gcc/c/ChangeLog: * c-typeck.cc (build_counted_by_ref): Handle pointers with counted_by. (build_access_with_size_for_counted_by): Likewise. gcc/ChangeLog: * tree-object-size.cc (access_with_size_object_size): Handle pointers with counted_by. (collect_object

[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

[PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

For example: struct PP { size_t count2; char other1; char *array2 __attribute__ ((counted_by (count2))); int other2; } *pp; specifies that the "array2" is an array that is pointed by the pointer field, and its number of elements is given by the field "count2" in the same structure. gcc/c-

[PATCH v4 0/3] extend "counted_by" attribute to pointer fields of structures

Hi, This is the 4th version of the patch set to extend "counted_by" attribute to pointer fields of structures. compared to the 3rd version: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682310.html https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682312.html https://gcc.gnu.org/piper

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

On Tue, 13 May 2025 at 23:34, Jason Merrill wrote: > > On 5/13/25 4:29 PM, Ville Voutilainen wrote: > > On Tue, 13 May 2025 at 23:23, Jason Merrill wrote: > >>>/* Check that the return and argument types are sane before > >>> folding. */ > >>> - if (INDIRECT_TYP

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

On 5/12/25 5:03 PM, Owen Avery wrote: Please add a little rationale for the change here, perhaps adapting the one from your previous patch. gcc/cp/ChangeLog: * method.cc (synthesized_method_walk): Check whether -Wvirtual-move-assign The (function) should usually go on the s

[PATCH] gimple: allow fold_stmt without setting cfun in case of GIMPLE_COND folding

This is the followup mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683444.html . It adds the check for cfun before accessing function specific flags. We handle the case where !cfun as conservative in that it the function might throw. gcc/ChangeLog: * gimple-fold.cc (re

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

On 5/13/25 4:29 PM, Ville Voutilainen wrote: On Tue, 13 May 2025 at 23:23, Jason Merrill wrote: /* Check that the return and argument types are sane before folding. */ - if (INDIRECT_TYPE_P (TREE_TYPE (x)) - && INDIRECT_TYPE_P (TREE_TYPE (r))) +

[patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

Hello world, this fixes the other regression which crept in with gfortran. Again, regression-tested, plus the local testing script is attached. Ok for trunk and gcc-15? Best regards Thomas Fix explicit arrays with non-constant size for -fc-prototypes. gcc/fortran/ChangeLog:

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

On Tue, 13 May 2025 at 23:23, Jason Merrill wrote: > > /* Check that the return and argument types are sane before > > folding. */ > > - if (INDIRECT_TYPE_P (TREE_TYPE (x)) > > - && INDIRECT_TYPE_P (TREE_TYPE (r))) > > + if (id_equal (DECL_NAME (

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

On 5/12/25 4:32 PM, Ville Voutilainen wrote: This function is yet another stdlib function that is just a simple cast, so having it appear while debugging is arguably not useful. So add it to the existing handling that always-folds some stdlib functions. Add std::to_underlying to the set of std

Re: [PATCH v1] libstdc++: More efficient weekday from year_month_day.

Adding link for xref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120264 Thanks, Cassio. On Mon, 12 May 2025 at 10:06, Jonathan Wakely wrote: > On Sun, 11 May 2025 at 12:34, Cassio Neri wrote: > > > > Hi all, > > > > After reflecting on my previous message and Andrew's, I now believe this > pa

[patch, Fortran] Fix 15/16 regression when non-interoperable types were dumped

Hello world, the attached patch fixes a 15/16 regression and should be fairly self-explanatory. Regarding testing: I'm not sure I am up to the task of hacking dejagnu to do this. I am now running local tests, which is better than nothing (I guess). Regression-testing: Passed, though this does n

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

On 5/13/25 10:56 AM, Alejandro Colomar wrote: 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/submi

Re: [PATCH] libstdc++: Preserve the argument type in basic_format_args [PR119246]

On 30/04/25 13:23 +0200, Tomasz Kamiński wrote: This commits adjust the way how the arguments are stored in the _Arg_value (and thus basic_format_args), by preserving the types of fixed width floating-point types, that were previously converted to float, double, long double. The _Arg_value union

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 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 2/2] forwprop: Move around the marking bb for eh to after the local non-fold_stmt optimizations

When moving the optimize_memcpy_to_memset optimization to forwprop from fold_stmt, the marking of the bb to purge for eh cleanup was not happening for the local optimizations but only after the fold_stmt, this causes g++.dg/torture/except-2.C to fail. So this patch moves the marking of the bbs fo

Re: [PATCH] c++/modules: Fix handling of -fdeclone-ctor-dtor with explicit instantiations [PR120125]

On 5/9/25 11:48 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15? One slight concern I have is why we end up in 'maybe_thunk_body' to start with: the imported constructor isn't DECL_ONE_ONLY (as its external) and so 'can_alias_cdtor' returns false.

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

On Tue, 13 May 2025, Tamar Christina wrote: > > -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 > > > >

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

[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

Re: [Patch, RFC] git_update_version.py: Support vendor-branch version bumps

On 5/13/25 02:22, Tobias Burnus wrote: 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

Stepping down as aarch64 port maintainer

Hello GCC Community, Many years have past since I actively worked on the aarch64 backend, so this email is long over due. I’ll be leaving Arm shortly so this seems like a good time to formerly step down as an AArch64 maintainer. It has been a privilege to contribute to GCC and to work alongside

[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

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

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

[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

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

[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

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

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

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

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

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

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

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

  1   2   >