[PATCH] expand: Fix up edge splitting for GIMPLE_COND expansion if there are any PHIs [PR120629]

Hi! My r16-1398 PR120434 ranger during expansion change broke profiled lto bootstrap on x86_64-linux, the following testcase is reduced from that. The problem is during expand_gimple_cond, if we are unlucky that neither of edge_true and edge_false point to the next basic block, the code effective

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

> This series is OK. Consider similar patches that handle vmin and > unsigned variants pre-approved as well assuming they follow the same > basic structure. I see, thanks Jeff, will commit the series if no surprise from CI. Pan -Original Message- From: Jeff Law Sent: Thursday, June

[PING][PATCH v3] reassoc: Optimize CMP/XOR expressions [PR116860]

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html . Thanks, Konstantinos

Re: [PATCH] fortran: add intrinsic doc for trig functions with half revolutions

Hi Yuao, Yuao Ma wrote: Fixed in this patch. Thinking about tex is always a pain... > Additionally, I think all "half-revolutions" should be "half revolutions" Thanks! I have another nit:     * intrinsic.texi: Add new doc. Reorder doc for atand. The first part is not really clear. I hav

Re: [PATCH] libstdc++: Do not specialize std::formatter for incomplete type [PR120625]

On Thu, Jun 12, 2025 at 12:04 AM Jonathan Wakely wrote: > Using an incomplete type as the template argument for std::formatter > specializations causes problems for program-defined specializations of > std::formatter which have constraints. When the compiler has to find > which specialization of

[r16-1429 Regression] FAIL: g++.target/i386/vect-pragma-target-2.C -std=gnu++98 (test for excess errors) on Linux/x86_64

On Linux/x86_64, dcb9af06212e8bb36e84a1b8498c625c29abeb6f is the first bad commit commit dcb9af06212e8bb36e84a1b8498c625c29abeb6f Author: Gwenole Beauchesne Date: Mon Jun 2 14:44:55 2025 -0700 c/c++: Handle '#pragma GCC target optimize' early [PR48026] caused FAIL: gcc.target/i386/vect-p

[PATCH v1 2/5] RISC-V: Add test for vec_dup + vmax.vv combine case 0 with max func 0 and GR2VR cost 0, 2 and 15

From: Pan Li Add asm dump check test for vec_duplicate + vmax.vv combine to vmax.vx, with the GR2VR cost is 0, 2 and 15. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add asm check for max func 1 vmax.vx combine. * gcc.target/riscv/rvv/autovec

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

From: Pan Li This patch would like to introduce the combine of vec_dup + vmax.vv into vmax.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: | .

[r16-1429 Regression] FAIL: g++.target/i386/vect-pragma-target-2.C -std=gnu++98 (test for excess errors) on Linux/x86_64

On Linux/x86_64, dcb9af06212e8bb36e84a1b8498c625c29abeb6f is the first bad commit commit dcb9af06212e8bb36e84a1b8498c625c29abeb6f Author: Gwenole Beauchesne Date: Mon Jun 2 14:44:55 2025 -0700 c/c++: Handle '#pragma GCC target optimize' early [PR48026] caused FAIL: gcc.target/i386/vect-p

[PATCH v1 5/5] RISC-V: Add test for vec_dup + vmax.vv combine case 1 with max func 1 and GR2VR cost 0, 1 and 2

From: Pan Li Add asm dump check test for vec_duplicate + vmax.vv combine to vmax.vx, with the GR2VR cost is 0, 1 and 2. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add asm check for vmax.vx combine. * gcc.target/riscv/rvv/autovec/vx_vf/vx-4-

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

On 6/11/25 9:12 PM, pan2...@intel.com wrote: From: Pan Li This patch would like to introduce the combine of vec_dup + vmax.vv into vmax.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

[PATCH v1 4/5] RISC-V: Add test for vec_dup + vmax.vv combine case 1 with max func 0 and GR2VR cost 0, 1 and 2

From: Pan Li Add asm dump check test for vec_duplicate + vmax.vv combine to vmax.vx, with the GR2VR cost is 0, 1 and 2. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add asm check for vmax.vx combine. * gcc.target/riscv/rvv/autovec/vx_vf/vx-4-

[PATCH] i386: Set SRF, GRR, CWF, GNR, DMR, ARL and PTL issue rate

Hi, This patch aims to set SRF issue rate to 4, GNR issue rate to 6. According to tests about spec2017, the patch has little effect on performance. For GRR, CWF, DMR, ARL and PTL, the patch set their issue rate to 6. Waiting for more information to update. Bootstrapped and regtested on x86_64-li

[wwwdocs] Add C23 status table

This patch adds the C23 Support in GCC table (compiler features only). While creating it, I've consulted Annex M.2, our own changes.html, Joseph's "ISO C23 support in the GNU Toolchain" Cauldron presentation, https://en.cppreference.com/w/c/compiler_support.html, https://clang.llvm.org/c_status.ht

Re: [PATCH V5] RISC-V: Prevent speculative vsetvl insn scheduling

On 6/10/25 2:55 PM, Vineet Gupta wrote: On 6/10/25 13:35, Edwin Lu wrote: The instruction scheduler appears to be speculatively hoisting vsetvl insns outside of their basic block without checking for data dependencies. This resulted in a situation where the following occurs vsetvl

Patch for bugzilla ticket 117366

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117366 where it was suggested I send this bug fix as a patch to gcc-patches. I have never submitted to this alias so I apologize if I am not "doing it right", but here is the diff, and the Bugzilla ticket has an example written up with good/bad as

Re: [PATCH] emit-rtl: Use simplify_subreg_regno to validate hardware subregs [PR119966]

On 6/9/25 12:40 PM, Dimitar Dimitrov wrote: On Sun, Jun 08, 2025 at 09:09:44AM -0600, Jeff Law wrote: On 6/5/25 2:16 PM, Dimitar Dimitrov wrote: PR119966 showed that combine could generate unfoldable hardware subregs for pru-unknown-elf. To fix, strengthen the checks performed by validate

Re: [PATCH v5 09/24] Add assembler_name to cgraph_function_version_info.

On 6/11/25 6:03 AM, Alfie Richards wrote: On 04/06/2025 15:59, Jeff Law wrote: On 5/29/25 6:46 AM, Alfie Richards wrote: Add the assembler_name member to cgraph_function_version_info to store the base assembler name of the funciton set, before FMV mangling. This is Just a typo in the pat

Re: [PATCH] RISC-V: Use scratch reg for Rd , so that src/rs2 is not clobbered for Store-Conditional.

On 6/11/25 3:25 AM, Kito Cheng wrote: LGTM, but I would like to make sure either Jeff or Patrick is OK too :) I think it's correct. Not sure why it was written in that original form, but conceptually the register value written by the "sc" is used at the "bnez" and dies at that point. So t

Re: [PATCH] simplify-rtx.cc:Simplify XOR(AND(ROTATE(~1), A), ASHIFT(1, A)) to IOR

On 6/11/25 9:53 AM, Richard Sandiford wrote: +into B | (1 << A). */ + if (GET_CODE (op0) == AND + && GET_CODE (XEXP (op0, 0)) == ROTATE + && CONST_INT_P (XEXP (XEXP (op0, 0), 0)) + && INTVAL (XEXP (XEXP (op0, 0), 0)) == -2 + && GET_CODE (op1) ==

[PATCH 7/45, V2] PR target/117251: Improve vector orc to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #7 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VORC' instruction feeding

[PATCH v2] libstdc++: Use hidden friends for __normal_iterator operators

As suggested by Jason, this makes all __normal_iterator operators into friends so they can be found by ADL and don't need to be separately exported in module std. The operator<=> comparing two iterators of the same type is removed entirely, instead of being made a hidden friend. That overload was

[PATCH] libstdc++: Fix std::uninitialized_value_construct for arrays [PR120397]

The std::uninitialized_{value,default}_construct{,_n} algorithms should be able to create arrays, but that currently fails because when an exception happens they clean up using std::_Destroy and in C++17 that doesn't support destroying arrays. (For C++20 and later, std::destroy does handle destroyi

[PATCH] libstdc++: Do not specialize std::formatter for incomplete type [PR120625]

Using an incomplete type as the template argument for std::formatter specializations causes problems for program-defined specializations of std::formatter which have constraints. When the compiler has to find which specialization of std::formatter to use for the incomplete type it considers the pro

[committed] libstdc++: Add _GLIBCXX_USE_BUILTIN_TRAIT to Doxygen config

This ensures that Doxygen sees the simpler definitions of type traits, which are implemented using the built-ins. Also add _GLIBCXX_HAVE_ICONV (which is less important) and fix some typos for _GLIBCXX_BEGIN_INLINE_ABI_NAMESPACE and _GLIBCXX_END_INLINE_ABI_NAMESPACE. libstdc++-v3/ChangeLog:

[committed] libstdc++: Remove redundant parentheses in preprocessor condition

Also indent the group controlled by the condition. libstdc++-v3/ChangeLog: * libsupc++/exception: Remove redundant parentheses and adjust whitespace. --- Tested x86_64-linux. Pushed to trunk. libstdc++-v3/libsupc++/exception | 6 +++--- 1 file changed, 3 insertions(+), 3 deleti

[committed] libstdc++: Fix mismatched @cond and @endcond in

I messed up the Doxygen conditionals in r16-1077-gb32bf304793047. libstdc++-v3/ChangeLog: * include/std/type_traits: Restore @cond and @endcond balance. --- Tested x86_64-linux. Pushed to trunk. libstdc++-v3/include/std/type_traits | 3 +++ 1 file changed, 3 insertions(+) diff --git a

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

On Wed, 11 Jun 2025, Qing Zhao wrote: > Then how about the following case: > > typedef struct item3 Item3; > struct pointer_array_9 { > > int count3; > Item3 *array_3 __attribute__ ((counted_by (count3))); > } > > struct item3 { > int a; > float b[]; > } > > In the above, the “Item3”

Re: [PATCH, part1] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]

On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote: > > the attached patch is a first attempt to fix some issues with the GNU > intrinsics STAT/LSTAT/FSTAT which are g77 heritage. This patch is > preparatory for dealing with the issue reported in PR82480 in that > the default version o

Re: [PATCH] c++,coroutines: Handle await expressions in assume attributes.

On 6/9/25 4:12 PM, Iain Sandoe wrote: Hi Jason, There was some discussion of this in the PR116775 comments. In the end I have matched what clang does in this circumstance, since that seems reasonable - and we may ignore the attributes as needed. tested on x86-64-darwin, powerpc64le-linux, OK for

Re: [PATCH] c++, coroutines: Handle builtin_constant_p [PR116775].

On 6/9/25 4:09 PM, Iain Sandoe wrote: Hi Jason, As discussed in the PR, fold the expression in the coroutine lowering. tested on x86_64-darwin, powerpc64le-linux, OK for trunk? thanks Iain --- 8< --- Since the folding of this builtin happens after the main coroutine FE lowering, we need to acco

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

> On Jun 11, 2025, at 15:45, Joseph Myers wrote: > > On Wed, 11 Jun 2025, Qing Zhao wrote: > >> When I was adding more testing cases for the pointee type being >> structure/union, I have a question for the following case: >> >> struct item5 { >> int a; >> float b[]; >> }; >> >> struct poi

[PATCH 45/45, V2] PR target/117251: Add tests

This is patch #45 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VAND' instruction feeding into 'VNAND'. The 'XXEVAL' instruction can use all 64 vector registers, instead of the 32 registers that traditional Altivec vector instructions use. By allow

Re: [PATCH] c++, coroutines: Handle unevaluated contexts

On 6/9/25 4:06 PM, Iain Sandoe wrote: Tested on x86_64-darwin, powerpc64le-linux, OK for trunk? thanks Iain --- 8< -- From [expr.await]/2 We should not accept co_await, co_yield in unevaluated contexts. It seems that we had not been marking typeid expressions as unevaluated so that is also a

[committed] cobol: Eliminate unguarded clock_gettime dependencies. [PR119975]

Subject: [PATCH] cobol: Eliminate unguarded clock_gettime dependencies. [PR119975] These changes are help make it possible to compile on MacOS. In addition to guarding clock_settime() calls, it removes the use of structures and constants needed for clock_settime(). --- libgcobol/intrinsic.cc |

[PATCH 42/45, V2] PR target/117251: Improve vector xor to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #42 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VXOR' instruction feedin

[PATCH 29/45, V2] PR target/117251: Improve vector eqv to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #29 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VEQV' instruction feedin

[PATCH 24/45, V2] PR target/117251: Improve vector or to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #24 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VOR' instruction feeding

[PATCH 44/45, V2] PR target/117251: Improve vector and to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #44 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VAND' instruction feedin

[PATCH, part1] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]

Dear all, the attached patch is a first attempt to fix some issues with the GNU intrinsics STAT/LSTAT/FSTAT which are g77 heritage. This patch is preparatory for dealing with the issue reported in PR82480 in that the default version of theses intrinsics use INTEGER(KIND=4) results that may overf

[PATCH 31/45, V2] PR target/117251: Improve vector orc to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #31 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VORC' instruction feedin

[PATCH 14/45, V2] PR target/117251: Improve vector andc to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #14 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VANDC' instruction feedi

[PATCH 38/45, V2] PR target/117251: Improve vector orc to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #38 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VORC' instruction feedin

[PATCH 41/45, V2] PR target/117251: Improve vector or to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #41 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VOR' instruction feeding

[PATCH 43/45, V2] PR target/117251: Improve vector andc to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #43 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VANDC' instruction feedi

[PATCH 5/45, V2] PR target/117251: Improve vector nor to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #5 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNOR' instruction feeding

[PATCH 18/45, V2] PR target/117251: Improve vector eqv to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #18 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VEQV' instruction feedin

[PATCH 30/45, V2] PR target/117251: Improve vector orc to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #30 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VORC' instruction feedin

[PATCH 12/45, V2] PR target/117251: Improve vector and to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #12 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VAND' instruction feedin

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

On Wed, 11 Jun 2025, Qing Zhao wrote: > When I was adding more testing cases for the pointee type being > structure/union, I have a question for the following case: > > struct item5 { > int a; > float b[]; > }; > > struct pointer_array_9 { >... > int count5; > struct item5 *array_5

[PATCH 28/45, V2] PR target/117251: Improve vector eqv to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #28 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VEQV' instruction feedin

[PATCH 40/45, V2] PR target/117251: Improve vector nor to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #40 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNOR' instruction feedin

[PATCH 16/45, V2] PR target/117251: Improve vector orc to vector eqv fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #16 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VORC' instruction feedin

[PATCH 26/45, V2] PR target/117251: Improve vector nor to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #26 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNOR' instruction feedin

[PATCH 21/45, V2] PR target/117251: Improve vector nor to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #21 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNOR' instruction feedin

[PATCH 3/45, V2] PR target/117251: Improve vector xor to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #3 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VXOR' instruction feeding

[PATCH 22/45, V2] PR target/117251: Improve vector or to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #22 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VOR' instruction feeding

[PATCH 25/45, V2] PR target/117251: Improve vector nor to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #25 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNOR' instruction feedin

[PATCH 37/45, V2] PR target/117251: Improve vector nand to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #37 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNAND' instruction feedi

[PATCH 39/45, V2] PR target/117251: Improve vector eqv to vector nand fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #39 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VEQV' instruction feedin

[PATCH 20/45, V2] PR target/117251: Improve vector xor to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #20 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VXOR' instruction feedin

[PATCH 33/45, V2] PR target/117251: Improve vector andc to vector eqv fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #33 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VANDC' instruction feedi

[PATCH 32/45, V2] PR target/117251: Improve vector andc to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #32 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VANDC' instruction feedi

[PATCH 17/45, V2] PR target/117251: Improve vector orc to vector orc fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #17 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VORC' instruction feedin

[PATCH 34/45, V2] PR target/117251: Improve vector and to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #34 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VAND' instruction feedin

[PATCH 27/45, V2] PR target/117251: Improve vector xor to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #27 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VXOR' instruction feedin

[PATCH 13/45, V2] PR target/117251: Improve vector andc to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #13 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VANDC' instruction feedi

[PATCH 8/45, V2] PR target/117251: Improve vector andc to vector andc fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #8 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VANDC' instruction feedin

[PATCH 36/45, V2] PR target/117251: Improve vector nand to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #36 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNAND' instruction feedi

[PATCH 23/45, V2] PR target/117251: Improve vector or to vector or fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #23 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VOR' instruction feeding

Re: [PATCH v6 9/8] libstdc++: Uglify __mapping_alike template parameter and fix test and typo in comment.

On Thu, 5 Jun 2025 at 16:21, Tomasz Kamiński wrote: > > When the static assert was generated from instantiations of default member > initializer of class B, the error was not generated for B<1, std::layout_left, > std::layout_left> case, only when -D_GLIBCXX_DEBUG was set. Changing B calls > to >

[PATCH 6/45, V2] PR target/117251: Improve vector eqv to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #6 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VEQV' instruction feeding

[PATCH 9/45, V2] PR target/117251: Improve vector nand to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #9 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNAND' instruction feedin

[PATCH 35/45, V2] PR target/117251: Improve vector nand to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #35 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNAND' instruction feedi

Re: [PATCH v6 3/8] libstdc++: Add tests for layout_left.

On Thu, 5 Jun 2025 at 12:23, Luc Grosheintz wrote: > > > > On 6/5/25 10:18, Tomasz Kaminski wrote: > > On Wed, Jun 4, 2025 at 5:15 PM Luc Grosheintz > > wrote: > > > >> Implements a suite of tests for the currently implemented parts of > >> layout_left. The individual tests are templated over the

[PATCH 15/45, V2] PR target/117251: Improve vector orc to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #15 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VORC' instruction feedin

[PATCH 2/45, V2] PR target/117251: Improve vector andc to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #2 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VANDC' instruction feedin

Re: [PATCH v2] c: remaining fix for the composite type inconsistency [PR120510]

On Wed, 11 Jun 2025, Uecker, Martin wrote: > c: remaining fix for the composite type inconsistency [PR120510] > > There is an old GNU extension which allows overriding the > promoted old-style arguments when there is an earlier prototype > An example (from a test added for PR1

[PATCH 4/45, V2] PR target/117251: Improve vector or to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #4 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VOR' instruction feeding

[PATCH 10/45, V2] PR target/117251: Improve vector nand to vector nor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #10 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VNAND' instruction feedi

[PATCH 11/45, V2] PR target/117251: Improve vector and to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #11 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VAND' instruction feedin

[pushed: r16-1422] diagnostics: add selftests for html_token_printer [PR116792]

No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r16-1422-gf867196566c8aa. gcc/ChangeLog: PR other/116792 * diagnostic-format-html.cc: Include "selftest-xml.h". (html_builder::make_element_for_diagnostic): Mov

[PATCH 1/45, V2] PR target/117251: Improve vector and to vector and fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #1 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VAND' instruction feeding

Re: [PATCH 4/4] libstdc++: Rework formatting of empty chrono-spec for duration.

On Fri, Jun 6, 2025 at 12:55 PM Tomasz Kamiński wrote: > In contrast to other calendar types if empty chron-spec is used for > duration > we are required to format it (and it's representation type) via ostream. > Handling this case was now moved to be part of the format function > for duration. T

[PATCH 19/45, V2] PR target/117251: Improve vector xor to vector xor fusion

See the following post for a complete explanation of what the patches for PR target/117251: * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html This is patch #19 of 45 to generate the 'XXEVAL' instruction on power10 and power11 instead of using the Altivec 'VXOR' instruction feedin

Re: [PATCH v6 1/8] libstdc++: Improve naming, whitespace and silence warnings for extents.

On Wed, 4 Jun 2025 at 16:00, Luc Grosheintz wrote: > > libstdc++-v3/ChangeLog: > > * include/std/mdspan(__mdspan::_ExtentsStorage): Change name > of private member _M_dynamic_extens to _M_dyn_exts. > * include/std/mdspan(extents): Change name of private member > fro

Re: [PATCH v6 3/8] libstdc++: Add tests for layout_left.

On Wed, 4 Jun 2025 at 16:15, Luc Grosheintz wrote: > > Implements a suite of tests for the currently implemented parts of > layout_left. The individual tests are templated over the layout type, to > allow reuse as more layouts are added. > > libstdc++-v3/ChangeLog: > > * testsuite/23_conta

Re: Gimple lowering question

On Wed, Jun 11, 2025, 9:24 AM Andrew MacLeod wrote: > > On 6/11/25 11:02, Andrew MacLeod wrote: > > > > On 6/10/25 17:05, Richard Biener wrote: > >> > >> > >>> Am 10.06.2025 um 22:18 schrieb Andrew MacLeod : > >>> > >>>  > >>> > >>> I had a question asked of me, and now I'm passing the buck. > >

Re: [PATCH v6 6/8] libstdc++: Implement layout_stride from mdspan.

On Wed, 4 Jun 2025 at 16:16, Luc Grosheintz wrote: > > Implements the remaining parts of layout_left and layout_right; and all > of layout_stride. > > The implementation of layout_stride::mapping::is_exhaustive applies > the following change to the standard: > > 4266. layout_stride::mapping shou

Re: [PATCH v6 2/8] libstdc++: Implement layout_left from mdspan.

On Wed, 4 Jun 2025 at 16:00, Luc Grosheintz wrote: > > Implements the parts of layout_left that don't depend on any of the > other layouts. > > libstdc++-v3/ChangeLog: > > * include/std/mdspan (layout_left): New class. > * src/c++23/std.cc.in: Add layout_left. > > Signed-off-by: Lu

Re: [PATCH] c++, coroutines: Ensure that the resumer is marked as can_throw.

On 6/9/25 3:54 PM, Iain Sandoe wrote: I was planning to apply this as obvious - but it is needed for the next patch to be posted - so noting here now. I discussed with one of the original coroutines paper authors the idea that, if the original function was marked noexcept, then we should carry t

[PATCH 0/45, V2] PR target/117251: Add PowerPC XXEVAL support to speed up SHA3 calculations

History: This is version 2 of the patch. In the original patch, all 44 fusion opportunities were lumped together in one patch. Outside of fusion.md, these changes are fairly small, in that it adds one alternative to each of the fusion patterns to add xxeval support. Fusion.md is a generated file

Re: [PATCH] c++, coroutines: Ensure that the resumer is marked as can_throw.

> On 11 Jun 2025, at 17:53, Jason Merrill wrote: > > On 6/9/25 3:54 PM, Iain Sandoe wrote: >> I was planning to apply this as obvious - but it is needed for the >> next patch to be posted - so noting here now. I discussed with one >> of the original coroutines paper authors the idea that, if

Re: [PATCH v3] c++, coroutines: CWG2563 promise lifetime extension [PR115908].

On 6/9/25 4:04 PM, Iain Sandoe wrote: Hi Jason, A complete re-implementation using a reference count as you suggested in response to discussions of remaining issues. I also discussed some of the points we encountered with one of the original coroutines authors; it is accepted that having two pl

Re: [PATCH] c, c++: Save 8 bytes of memory in lang_type for non-ObjC*

On 6/9/25 6:12 PM, Joseph Myers wrote: On Mon, 9 Jun 2025, Jakub Jelinek wrote: Hi! For C++26 P2786R13 I'm afraid I'll need 4 new flags on class types in struct lang_type (1 bit for trivially_relocatable_if_eligible, 1 for replaceable_if_eligible, 1 for not_trivially_relocatable and 1 for not_

Re: [PATCH v6 5/8] libstdc++: Add tests for layout_right.

On Wed, 4 Jun 2025 at 16:15, Luc Grosheintz wrote: > > Adds tests for layout_right and for the parts of layout_left that depend > on layout_right. > > libstdc++-v3/ChangeLog: > > * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add > tests for layout_right. >

Re: [PATCH v2] c++, coroutines: Avoid UNKNOWN_LOCATION synthesizing code [PR120273].

On 6/9/25 3:43 PM, Iain Sandoe wrote: Hi Jason, This replaces "c-lex: Handle NULL filenames from UNKNOWN_LOCATION" as we discussed off-list, you prefer a solution that has valid locations during the synthesis. I have reverted to using the function location for code that represents start-up and

Re: [PATCH v6 7/8] libstdc++: Add tests for layout_stride.

On Wed, 4 Jun 2025 at 16:26, Luc Grosheintz wrote: > > Implements the tests for layout_stride and for the features of the other > two layouts that depend on layout_stride. > > libstdc++-v3/ChangeLog: > > * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add > tests for

Re: [PATCH] libstdc++: Test for precision and floting point durations.

On Wed, 11 Jun 2025 at 15:07, Tomasz Kamiński wrote: > > libstdc++-v3/ChangeLog: > > * testsuite/std/time/format/empty_spec.cc: New tests. > * testsuite/std/time/format/precision.cc: New test. > --- > Testing on x86_64-linux. OK for trunk when tests passes? OK (with the change to

Re: [PATCH v6 4/8] libstdc++: Implement layout_right from mdspan.

On Wed, 4 Jun 2025 at 16:10, Luc Grosheintz wrote: > > Implement the parts of layout_left that depend on layout_right; and the > parts of layout_right that don't depend on layout_stride. > > libstdc++-v3/ChangeLog: > > * include/std/mdspan (layout_right): New class. > * src/c++23/s

  1   2   >