Re: [PATCH 2/2] cfglceanup: Fix check for preheaders

> Am 16.11.2025 um 06:26 schrieb Andrew Pinski : > > I had messed up the check in r16-5258-g1d8e2d51e5c5cb for preheaders > where return to remvoe the forwarder preheader block even if > LOOPS_HAVE_PREHEADERS > was set. I am not sure how often this happens because most of the time the > pre-

Re: [PATCH 2/2] cfglceanup: Fix check for preheaders

> Am 16.11.2025 um 06:26 schrieb Andrew Pinski : > > I had messed up the check in r16-5258-g1d8e2d51e5c5cb for preheaders > where return to remvoe the forwarder preheader block even if > LOOPS_HAVE_PREHEADERS > was set. I am not sure how often this happens because most of the time the > pre-

[PATCH] configure: Support disabling specific languages [PR12407]

Hello- This patch makes it easier to disable a specific language, which is a need that comes up from time to time. I have tested it by trying a variety of combinations of --enable-languages arguments on the following platforms: x86_64-linux-gnu x86_64-pc-cygwin x86_64-w64-mingw32 aarch64-apple-da

[PATCH 2/2] cfglceanup: Fix check for preheaders

I had messed up the check in r16-5258-g1d8e2d51e5c5cb for preheaders where return to remvoe the forwarder preheader block even if LOOPS_HAVE_PREHEADERS was set. I am not sure how often this happens because most of the time the pre-header will have an incoming phi block anyways but it is safer not

[PATCH 1/2] mergephi: Add stats

This just adds a simple stats recording. Main reason is that I want to find out if we can remove one of the mergephi now. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * tree-cfgcleanup.cc (pass_merge_phi::execute): Add stats for the removed blocks. Signed-off-by:

[PATCH] LoongArch: Fix wrong code from loongarch_expand_vec_perm_1 [PR 122695]

PR target/122695 gcc/ * config/loongarch/loongarch.cc (loongarch_expand_vec_perm_1): Simplify and fix the logic preventing the xvshuf.* unpredictable behavior. gcc/testsuite/ * gcc.target/loongarch/pr122695-1.c: New test. * gcc.target/loongarch/pr

Re: [PATCH] RISC-V: Add RTL pass to combine cm.popret with zero return value

On 11/5/25 7:50 AM, Kito Cheng wrote: This patch implements a new RTL pass that combines "li a0, 0" and "cm.popret" into a single "cm.popretz" instruction for the Zcmp extension. This optimization cannot be done during prologue/epilogue expansion because it would cause shrink-wrapping to gene

[PUSHED] aarch64: unxfail pr117123.C

This testcase now passes for aarch64 after r16-5258-1d8e2d51e5c5. The keeping around the loop pre-header helped to better thread the jumps and fix the issue at hand. Pushed as obvious. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/pr117123.C: un-xfail. Signed-off-by: Andrew Pinski --- gc

Re: [PATCH] Add early loop-invariant motion pass

On 11/15/25 5:02 AM, Richard Biener wrote: In principle the dependence analysis part of LIM is quadratic, but I have not seen actual cases in a long time where it would outcompete FRE or PRE in terms of compile time (but IIRC we do not put hard limits on the max work it does). I will look

Re: [PATCH] Change the default C++ dialect to gnu++20

On Sat, 15 Nov 2025 at 23:07, Jakub Jelinek wrote: > > On Mon, Nov 03, 2025 at 01:34:28PM -0500, Marek Polacek via Gcc wrote: > > I would like us to declare that C++20 is no longer experimental and > > change the default dialect to gnu++20. Last time we changed the default > > was over 5 years ag

[PATCH] libstdc++: Future-proof C++20 atomic wait/notify

This will allow us to extend atomic waiting functions to support a possible future 64-bit version of futex, as well as supporting futex-like wait/wake primitives on other targets (e.g. macOS has os_sync_wait_on_address and FreeBSD has _umtx_op). Before this change, the decision of whether to do a

[committed] libstdc++: Minor refactoring in __wait_until_impl in atomic.cc

libstdc++-v3/ChangeLog: * src/c++20/atomic.cc (__wait_impl): Fix outdated comment. (__wait_until_impl): Simplify return statements. --- Tested x86_64-linux and sparc-solaris. Pushed to trunk. libstdc++-v3/src/c++20/atomic.cc | 14 +- 1 file changed, 5 insertions(+),

[committed] libstdc++: Tweak static_assert messages for volatile atomic waits

libstdc++-v3/ChangeLog: * include/bits/atomic_base.h: Tweak grammar of static assert messages for unsupported atomic wait on volatile. --- Tested x86_64-linux and sparc-solaris. Pushed to trunk. libstdc++-v3/include/bits/atomic_base.h | 9 ++--- 1 file changed, 6 insertions(

[PATCH v2] c++/modules: Keep tracking instantiations of static class variable templates [PR122625]

On Sat, Nov 15, 2025 at 10:54:55PM +1100, Nathaniel Shead wrote: > On Sat, Nov 15, 2025 at 10:32:00AM +0530, Jason Merrill wrote: > > On 11/15/25 9:47 AM, Nathaniel Shead wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk and 15? > > > > > > -- >8 -- > > > > > > r16-4930

[to-be-committed][RISC-V] Cleanup zero-extension patterns, generalize zero-extend with shifted operand

So this started off as a simple task -- upstream a hunk of code from the VRULL team that we've been using internally for a few years. With the prereqs out of the way I can finally bang on the patch I was really trying to move forward. The zero_extendsidi2_shifted can be generalized (after

[PATCH 1/2] c++: use nesting and counts in print_candidates

In r15-6116-gd3dd24acd74605 I updated print_z_candidates to print a count of the number of candidates, and to show the number of each candidate in the list if there is more than one. The following patch updates print_candidates to work in a similar way, showing counts, numbering, and using nesting

[PATCH 2/2] c++: UX improvements for close matches in print_candidates

This patch improves the UX for various cases of "no declaration matches" where print_candidates encounters a close match. For example, consider the const vs non-const here: class foo { public: void test (int i, int j, void *ptr, int k); }; // Wrong "const"-ness of param 3. void foo::test (int

[PATCH] Change the default C++ dialect to gnu++20

On Mon, Nov 03, 2025 at 01:34:28PM -0500, Marek Polacek via Gcc wrote: > I would like us to declare that C++20 is no longer experimental and > change the default dialect to gnu++20. Last time we changed the default > was over 5 years ago in GCC 11: >

[PATCH] GCC, meet C++20

Hi! I've tried to test a patch to switch -std=gnu++17 C++ default to -std=gnu++20 (will post momentarily), but ran into various problems during GCC bootstraps, our codebase isn't fully C++20 ready. The most common problems are arithmetic or bitwise operations between enumerators of different enum

[PATCH] c++: Implement C++23 P2246R1 - Character encoding of diagnostic text

Hi! The following patch attempts to implement the C++23 P2246R1 Character encoding of diagnostic text paper. Initially I thought there is nothing to do, but this patch shows that there is (and I wonder if we shouldn't backport it to release branches). Though the patch is on top of the cpp_transla

Re: [PATCH] aarch64: change another CRC test

Andrew Pinski writes: > On Sun, Mar 30, 2025 at 8:41 AM Sam James wrote: >> >> Fixed the iteration number in crc-crc32-data16.c test from 8 to 16 to >> match the test name, just like in r15-9038-gdf55a933cfc675. >> >> gcc/testsuite/ChangeLog: >> * gcc.target/aarch64/crc-crc32-data16.c: F

Re: [PATCH] aarch64: change another CRC test

On Sun, Mar 30, 2025 at 8:41 AM Sam James wrote: > > Fixed the iteration number in crc-crc32-data16.c test from 8 to 16 to > match the test name, just like in r15-9038-gdf55a933cfc675. > > gcc/testsuite/ChangeLog: > * gcc.target/aarch64/crc-crc32-data16.c: Fix iteration > count to

Re: [PATCH] gcc: Make aarch64-mingw32 target install wrap stdint.h

On Sun, Aug 3, 2025 at 3:21 PM Jason Xu wrote: > > Wrapped stdint.h for AArch64 MinGW32 is useful for bare-matal PE > target e.g. UEFI, as those platform does not provide a system > stdint.h, this would align with x86_64 mingw32 target which provides a > wrapped stdint.h > > I have tested this by

Re: [PATCH] libstdc++: Implement P3223R2 Making std::istream::ignore less surprising

On Sat, 15 Nov 2025 at 16:09, Yuao Ma wrote: > > On Thu, Nov 13, 2025 at 11:40 PM Jonathan Wakely wrote: > > > And I'm a bit confused here. Why does adding `_Tp = _CharT` prevent > > > the overload from appearing for wstream? I'm not sure what I'm > > > missing. > > > > Oops, my suggestion was mi

[pushed] c++/modules: explicit inst of constructor

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The extern template __shared_ptr in bits/fs_dir.h was leading to an ICE in import_export_decl in 29_atomics/atomic_ref/address.cc because we had the nonsensical combination of DECL_REALLY_EXTERN and !DECL_INTERFACE_KNOWN. This turned out to

[PATCH RFC] c++/modules: #include -> import

Tested x86_64-pc-linux-gnu. Any comments? -- 8< -- Since the standard library doesn't preclude an #include of a standard library header from bringing in declarations from other headers, we can translate an #include of any of the importable headers as an import of . To reduce the amount of C++ s

[PATCH RFC] driver/c++: add --compile-std-module

Tested x86_64-pc-linux-gnu. Any opinions? Bikeshedding of the flag name? -- 8< -- For simple testcases that want to use the std module, it would be useful to have a reasonably short way to request building the binary module form before the testcase. So with this patch users can write g++ -s

[to-be-committed][RISC-V] Eliminate zero-extension related define_insn_and_splits

So this is a slightly scaled back variant of a patch I've been working on. I'd originally planned to handle both zero and sign extensions, but there's some fallout with the sign extension adjustments that I'm going to need more time to tackle. This piece stands on its own and unlocks a subseq

Re: [PATCH] libstdc++: Implement P3223R2 Making std::istream::ignore less surprising

On Thu, Nov 13, 2025 at 11:40 PM Jonathan Wakely wrote: > > And I'm a bit confused here. Why does adding `_Tp = _CharT` prevent > > the overload from appearing for wstream? I'm not sure what I'm > > missing. > > Oops, my suggestion was missing this line before the #endif > > ignore(streamsize __n,

[PATCH 2/2] libstdc++: Use new atomic fetch min/max builtins in std::atomic

From: Soumya AR This patch enables libstdc++ to implement C++26's atomic min/max operations through the newly added compiler builtins. Similar to the __atomic_fetch_addable and __atomic_fetch_subtractable concepts, we implement the following concepts for min/max operations: __atomic_fetch_minab

[PATCH 1/2] middle-end: Add support for fetch min/max builtins via CAS lowering

From: Soumya AR This patch introduces support for atomic fetch min/max operations through a new internal function and gimple lowering pass. The implementation adds four new generic builtins to sync-builtins.def: - __atomic_fetch_min - __atomic_fetch_max - __atomic_min_fetch - __atomic_ma

[PATCH 0/2] Implement atomic fetch min/max in std::atomic

From: Soumya AR Hi, These patches are a continuation of our discussion here: [https://gcc.gnu.org/pipermail/gcc-patches/2025-November/699602.html] I've worked on implementing the CAS expansion for atomic fetch min/max so that the support for the builtins is available alongside the libstdc++ pat

Re: [PATCH 4/9] c++: C++26 Reflection [PR120775]

On Sat, 15 Nov 2025 at 08:47 +, Jonathan Wakely wrote: On Fri, 14 Nov 2025 at 19:37 -0500, Marek Polacek wrote: diff --git a/libstdc++-v3/src/c++23/std.cc.in b/libstdc++-v3/src/c++23/std.cc.in index 27d83f1ba1b..a75db1fe0a0 100644 --- a/libstdc++-v3/src/c++23/std.cc.in +++ b/libstdc++-v3/src

Re: [PATCH 4/9] c++: C++26 Reflection [PR120775]

On Sat, 15 Nov 2025 at 10:27, Jakub Jelinek wrote: > > On Sat, Nov 15, 2025 at 08:47:10AM +, Jonathan Wakely wrote: > > On Fri, 14 Nov 2025 at 19:37 -0500, Marek Polacek wrote: > > > This contains the libstdc++ bits (including ). > > > > Excliting! A few small changes requested below ... > > T

Re: [PATCH] cobol: Fix bootstrap [PR122691]

> Am 15.11.2025 um 11:12 schrieb Jakub Jelinek : > > Hi! > > Andrew's recent r16-5258 change broke bootstrap on x86_64-linux with > cobol enabled, the error is > ../../gcc/cobol/lexio.cc: In function > ‘std::pair, > char*> parse_replace_pairs(const char*, const char*, bool)’: > ../../gcc/cob

Re: [PATCH] testsuite: Fix up c-c++-common/asan/asan-stack-small.c test

> Am 15.11.2025 um 11:06 schrieb Jakub Jelinek : > > Hi! > > Here is a fix for the test I've talked about today in the libsanitizer > update mail. > > The test relied on a coming before b coming before c, all with 32 byte > distances, but gcc can actually emit them in the exact opposite orde

Re: [PATCH] Add early loop-invariant motion pass

> Am 15.11.2025 um 12:33 schrieb Jeff Law : > >  > >> On 11/14/25 8:09 AM, Richard Biener wrote: >> The testcases from PR121744 and PR121685 fail to be optimized when >> the method with the access based on 'this' is inlined. The following >> adds an early loop-invariant motion pass to combat

Re: [PATCH] Add early loop-invariant motion pass

> Am 15.11.2025 um 11:51 schrieb Andrew Pinski : > > On Fri, Nov 14, 2025 at 7:11 AM Richard Biener wrote: >> >> The testcases from PR121744 and PR121685 fail to be optimized when >> the method with the access based on 'this' is inlined. The following >> adds an early loop-invariant motion

Re: [PATCH] c++/modules: Keep tracking instantiations of static class variable templates [PR122625]

On Sat, Nov 15, 2025 at 10:32:00AM +0530, Jason Merrill wrote: > On 11/15/25 9:47 AM, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk and 15? > > > > -- >8 -- > > > > r16-4930-gfd5c057c2d01 ensured that we noted all class-scope variables. > > But I also

Re: [PATCH v1 4/6] libstdc++: Implement submdspan and submdspan_mapping for layout_left. [PR110352]

On 11/14/25 15:09, Luc Grosheintz wrote: Implements `submdspan` and `submdspan_mapping` for layout_left as described in P3663 (Future proofing mdspan). When computing the offset of the submdspan, one must check that the lower bound of the slice range isn't out-of-range. There's a few cases wh

Re: [PATCH] LoongArch: Add more numbers supported for {x}vldi

On Fri, 2025-11-14 at 10:04 +0800, Deng Jianbo wrote: /* snip */ > diff --git a/gcc/config/loongarch/loongarch.cc > b/gcc/config/loongarch/loongarch.cc > index 1f29de5f6e1..207af959b2e 100644 > --- a/gcc/config/loongarch/loongarch.cc > +++ b/gcc/config/loongarch/loongarch.cc > @@ -1941,8 +1941,1

Re: [PATCH] c++: Support template block-scope OpenMP user-defined reductions in modules [PR119864]

On Sat, Nov 15, 2025 at 10:42:30PM +1100, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? LGTM. DECL_OMP_DECLARE_REDUCTION_P decls aren't really functions, just an internal implementation detail to which it can attach the expressions from the pragmas or at

[PATCH] c++: Support template block-scope OpenMP user-defined reductions in modules [PR119864]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- There were two issues preventing OpenMP reductions of UDTs from working in modules. Firstly, we were failing a number of checking asserts in the streaming logic because the declaration is a DECL_LOCAL_DECL_P but was not co

[pushed] wwwdocs: gcc-12: Update link to "2020 Arm Architecture extensions"

Kudos to arm's web team for proper redirects (a 301 in this case). Pushed. Gerald --- htdocs/gcc-12/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index 153e9ae5..0a091123 100644 --- a/htdocs/gcc-12/changes

Re: [PATCH 4/9] c++: C++26 Reflection [PR120775]

On Sat, Nov 15, 2025 at 08:47:10AM +, Jonathan Wakely wrote: > On Fri, 14 Nov 2025 at 19:37 -0500, Marek Polacek wrote: > > This contains the libstdc++ bits (including ). > > Excliting! A few small changes requested below ... Thanks, I've added changes to https://forge.sourceware.org/marek/gc

Re: [PATCH] openmp, openacc: OpenMP/OpenACC tests. vs C++26

Hi Jakub, hello all, Jakub Jelinek wrote: As Marek mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2025-November/700733.html we have discovered a problem with C++26 vs. OpenMP/OpenACC array sections. OpenMP/OpenACC array sections, generally expr[expr:expr] or expr[expr:expr:expr] (OpenMP

Re: [PATCH 4/9] c++: C++26 Reflection [PR120775]

On Fri, 14 Nov 2025 at 19:37 -0500, Marek Polacek wrote: This contains the libstdc++ bits (including ). Excliting! A few small changes requested below ... -- >8 -- diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am index ae7a7ca9073..5fff459a779 100644 --- a/libs

[PATCH 6/6] PR target/118541 do not generate floating point cmoves for IEEE compares

In bug PR target/118541 on power9, power10, and power11 systems, for the function: extern double __ieee754_acos (double); double __acospi (double x) { double ret = __ieee754_acos (x) / 3.14; return __builtin_isgreater (ret, 1.0) ? 1.0 : ret;

[PATCH 5/6] PR target/12068 allow -mcmodel=large with PC relative addressing

When I implemented the pc-relative support for power10 in GCC, I disabled using pc-relative support for -mcmodel=large. At the time, I didn't want to dig into the issues. It is now time to allow -mcmodel=large to generate pc-relative code. This patch allows -mcmodel=large to use prefixed address

[PATCH 4/6] PR target/108958 simplify mtvsrdd to zero extend GPR DImode to VSX TImode

Before this patch GCC would zero extend a DImode GPR value to TImode by first zero extending the DImode value into a GPR TImode register pair, and then do a MTVSRDD to move this value to a VSX register. For example, consider the following code: #ifndef TYPE #define TYPE unsigned l

[PATCH 3/6] PR target/120528 Simplify zero extend from memory to VSX register on power10

Previously GCC would zero extend a DImode value in memory to a TImode target in a vector register by firt zero extending the DImode value into a GPR TImode register pair, and then do a MTVSRDD to move this value to a VSX register. For example, consider the following code: #ifndef TYPE

[PATCH 2/6] PR target/99293 Optimize splat of a V2DF/V2DI extract with constant element

We had optimizations for splat of a vector extract for the other vector types, but we missed having one for V2DI and V2DF. This patch adds a combiner insn to do this optimization. In looking at the source, we had similar optimizations for V4SI and V4SF extract and splats, but we missed doing V2DI

[PATCH 1/6] Add power9 and power10 float to logical optimizations

I was answering an email from a co-worker and I pointed him to work I had done for the Power8 era that optimizes the 32-bit float math library in Glibc. In doing so, I discovered with the Power9 and later computers, this optimization is no longer taking place. The glibc 32-bit floating point math

[PATCH 0/6] Various PowerPC PRs

I looked around the various patches that I've been keeping around. I figured I should re-submit them now. Each of these patches are independent of each others. I have built both little endian and big endian bootstrap GCC compilers on PowerPC servers. There were no regressions in the test suites