[RFC PATCH] c++: Implement current wording of https://github.com/cplusplus/CWG/issues/805

Hi! For the https://gcc.gnu.org/pipermail/gcc/2025-November/246977.html issues I've filed https://github.com/cplusplus/CWG/issues/805 and got there some responses. One possibility is to change the iterating expansion statement http://eel.is/c++draft/stmt.expand#5.2 line from constexpr auto&& rang

Re: [PATCH v2 0/2] c: Add _Maxof & _Minof [n3628, but rejecting _Bool]

Hi Joseph, On Fri, Nov 14, 2025 at 11:35:31PM +, Joseph Myers wrote: > On Fri, 14 Nov 2025, Alejandro Colomar wrote: > > > > In any case these patches aren't actually suitable for consideration at > > > present, given that the represent as part of C2y something that has not > > > so > > >

[pushed] c++/modules: if translation fails fall back to #include

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- If a user wrote #include and the .gcm we found won't work, instead of failing the compile let's do the #include that the source code called for. This case also prints a note about the failure, like those from -flang-info-include-translate{,

[pushed] c++/modules: fix hash_map issue

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Building std.compat.cc was crashing for me because we would first get a pointer into imported_temploid_friends, then insert a new entry, causing the hash_map to expand, and then dereference the pointer into the former location of the hash ta

[pushed] c++/modules: using builtin

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here, when we try to bring "memset" back into the global namespace, we find the built-in, see that it's the same declaration (because the module brought it into the other namespace with a using-declaration), and decide that we don't need to

Re: [PATCH 1/6] RISC-V: Change gather/scatter iterators.

> Just spot checked the pattern changes for sanity. The iterator changes are > mind-bending. CI is complaining: > >> ../../../gcc/gcc/config/riscv/vector-iterators.md:375:80: error: unknown >> mode `V1BF' Oh. Looks like I always tested with my older BF fix applied first. Need to conclude on

Re: [PATCH 3/4] ipa: Add early return when the hashed edge is a callback-carrying edge.

Josef Melcr writes: > The inclusion of this early return statement has been discussed before, > it was ultimately left out of the original patch, but it turns out to be > necessary. > > When a callback edge is being created, it is first created by > symbol_table::create_edge, which is where it is

[pushed] c++/modules: fix hash_map issue

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Building std.compat.cc was crashing for me because we would first get a pointer into imported_temploid_friends, then insert a new entry, causing the hash_map to expand, and then dereference the pointer into the former location of the hash ta

[pushed] c++/modules: using builtin

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here, when we try to bring "memset" back into the global namespace, we find the built-in, see that it's the same declaration (because the module brought it into the other namespace with a using-declaration), and decide that we don't need to

[pushed] c++/modules: friend void foo()

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- 23_containers/mdspan/layouts/padded.cc was failing because on load we were wrongly treating the __get_static_stride friends as equivalent between layout_left_padded and layout_right_padded. This happened because we were wrongly pushing thes

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

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 added a clause to 'read_var_def' to skip all class-scope instantiations, under the mist

[to-be-committed][RISC-V] Avoid most calls to gen_extend_insn

Yet more infrastructure on our way to eliminating some define_insn_and_split constructs. The RISC-V port is using gen_extend_insn to directly generate a SIGN or ZERO extend insn. This is undesirable because we don't actually have a full set of extension instructions, particularly zero exten

Re: [PATCH v2 1/3] Match: Simplify (T1)(a bit_op (T2)b) to (T1)a bit_op (T1)b

On Fri, Nov 14, 2025 at 7:26 PM wrote: > > From: Pan Li > > During the match pattern of SAT_U_MUL form 7, we found there is > a pattern like below: > > (nop_convert)(a bit_op (convert b)) > > which result in the pattern match of SAT_U_MUL complicated and > unintuitive. According to the suggestio

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

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 added a clause to 'read_var_def' to skip all class-scope instantiations, under the mistaken belief that this would be handled in read

[PATCH v2 2/3] Test: Add test case for bit_op convert folding

From: Pan Li Add test cases of all possible types of bit_op convert folding. To check there is no tree dump like below: _5 = (uint8_t) _2; return _5; gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/bit_op_cvt.1.c: New test. * gcc.dg/tree-ssa/bit_op_cvt.2.c: New test. *

[PATCH v2 3/3] Match: Remove unnecessary convert for unsigned SAT_MUL

From: Pan Li After we convert from bit_op outer into its captures, some outer convert of unsigned SAT_MUL form 6 is unnecessary any more. Thus, remove it. Meanwhile, add c after outer bit_ior to make the test happy. gcc/ChangeLog: * match.pd: Remove unnecessary outer convert and add

[PATCH v2 1/3] Match: Simplify (T1)(a bit_op (T2)b) to (T1)a bit_op (T1)b

From: Pan Li During the match pattern of SAT_U_MUL form 7, we found there is a pattern like below: (nop_convert)(a bit_op (convert b)) which result in the pattern match of SAT_U_MUL complicated and unintuitive. According to the suggestion of Richard, we would like to simply it to blew: (conve

[PATCH v2 0/3] Simplify (T1)(a bit_op (T2)b) to (T1)a bit_op (T1)b

From: Pan Li We notice such pattern during the form 7 support of the SAT_U_MUL. So we would like to perform the simplify before that. The below test suites are passed for this patch: 1. The rv64gcv fully regression tests. 2. The x86 bootstrap tests. 3. The x86 fully regression tests. Pan Li (3)

Re: [PATCH 2/6] RISC-V: Rename vector-mode related functions.

On 11/14/25 10:28 AM, Robin Dapp wrote: This patch just performs renaming from e.g. riscv_v_ext_vector_mode_p to riscv_vector_mode_p and similar. gcc/ChangeLog: * config/riscv/riscv-avlprop.cc (pass_avlprop::execute): * config/riscv/riscv-protos.h (riscv_v_ext_vector_mode

Re: [PATCH 1/6] RISC-V: Change gather/scatter iterators.

On 11/14/25 10:28 AM, Robin Dapp wrote: This patch changes the gather/scatter mode iterators from a ratio scheme to a more direct one where the index mode size is 1/2, 1/4, 1/8, 2, 4, 8 times the data mode size. It also adds VLS modes to the iterators and removes the now unnecessary gather_sc

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

This contains the libstdc++ bits (including ). -- >8 -- diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am index ae7a7ca9073..5fff459a779 100644 --- a/libstdc++-v3/include/Makefile.am +++ b/libstdc++-v3/include/Makefile.am @@ -89,6 +89,7 @@ std_headers = \ ${s

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

This contains the metafunction gperf bits. -- >8 -- diff --git a/gcc/cp/metafns.gperf b/gcc/cp/metafns.gperf new file mode 100644 index 000..4759cdfe463 --- /dev/null +++ b/gcc/cp/metafns.gperf @@ -0,0 +1,643 @@ +%language=C++ +%define class-name metafn_lookup +%struct-type +%{ +/* Copyrig

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

I'm going to split this patch in multiple pieces. Here I'm providing the description and the ChangeLog for the whole submission. It all needs to be committed at once. The whole branch can be found at Unfortunately, as I'm about

Re: [PATCH] RISC-V: Add flag to adjust mem inlining threshold

On 11/7/25 11:55 AM, Edwin Lu wrote: Add param flags to adjust the memcpy/memove/memset inlining threshold. The threshold can be updated with --param=-size-threshold= Default is currently set for disabled. gcc/ChangeLog: * config/riscv/riscv-string.cc (riscv_expand_block_move_scalar

Re: Ping: [PATCH] diagnostics: Fix -fdump-internal-locations for 64-bit location_t

On 11/10/25 4:55 PM, Lewis Hyatt wrote: Ping please? It would be great to tie up this loose end. Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692261.html -Lewis On Sun, Oct 12, 2025 at 9:44 AM Lewis Hyatt wrote: Hello- https://gcc.gnu.org/pipermail/gcc-patches/2025-Augu

[PATCH v2] c++: Implement dependent ADL for use with modules

On Sat, Nov 15, 2025 at 12:11:39AM +1100, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > An alternative implementation would be to do the additional lookups in > modules.cc during tree walk at the point we know we need to check for > any CALL_EXPR wit

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

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 this. I have added a knob on PHI-motion as I think this is nei

Re: [PATCH v2 0/2] c: Add _Maxof & _Minof [n3628, but rejecting _Bool]

On Fri, 14 Nov 2025, Alejandro Colomar wrote: > > In any case these patches aren't actually suitable for consideration at > > present, given that the represent as part of C2y something that has not so > > far been accepted into C2y. > > Okay, I'll resend as GNU extension (thus, adjusting diagno

[PATCH, 11/11] Add _Float16 and __bfloat16 tests.

This patch adds 4 tests to make sure 16-bit floating point is supported. float16-1.c: This simple test verifies that _Float16 operations work on ISA 2.07 (power8), ISA 3.0 (power9), and ISA 3.1 (power10 and power11) systems. On ISA 2.07 systems, the tests will be done via software emulation. On I

Re: [PATCH v2 0/2] c: Add _Maxof & _Minof [n3628, but rejecting _Bool]

Hi Joseph, On Fri, Nov 14, 2025 at 10:08:31PM +, Joseph Myers wrote: > On Fri, 14 Nov 2025, Alejandro Colomar wrote: > > Here's a second attempt at implementing these two operators. > > They're implemented as proposed in n3628, but differ slightly in that > > they reject _Bool (the first commi

[PATCH, 10/11] Add --with-powerpc-float16 and --with-powerpc-float16-disable-warning.

This patch adds 2 configuration options to GCC to enable better testing 16-bit floating point values. The --with-powerpc-float16 option will configure _Float16 and __bfloat16 to be automatically enabled on little endian PowerPC servers. Note, if this option is enabled, tests involving 16-bit floa

[PATCH, 9/11] Optimize __bfloat16 scalar code.

Optimize __bfloat16 binary operations. Unlike _Float16 where we have instructions to convert between HFmode and SFmode as scalar values, with BFmode, we only have vector conversions. Thus to do: __bfloat16 a, b, c; a = b + c; the GCC compiler generates the following code:

Re: [PATCH v2 0/2] c: Add _Maxof & _Minof [n3628, but rejecting _Bool]

On Fri, 14 Nov 2025, Alejandro Colomar wrote: > Hi, > > Here's a second attempt at implementing these two operators. > They're implemented as proposed in n3628, but differ slightly in that > they reject _Bool (the first commit message details a bit more about > this). I disagree with that langua

[PATCH, 8/11] Add 16-bit floating point vectorization.

This patch adds automatic vectorization of _Float16 values on ISA 3.0 (power9) systems, and automatic vectorization of __bfloat16 values on ISA 3.1 (power10 and power11) systems. This is done by converting the vector of 16-bit floating point to two vectors of 32-bit floating point values, doing th

[PATCH, 7/11] Add BF/HF negate and absolute value operations and logical insns.

This patch adds negation, absolute value and negative absolute value operations on scalar _Float16 and __bfloat16 values. In order to implement these operations, the logical operations (AND, IOR, XOR, etc.) that target the 16-bit floating point values have been added. All 11 patches have been tes

[committed][RISC-V] Drop scan-tests of marginal value

So one of Andrew's patches recently triggered numerous scan failures on the RISC-V port. It's our friends the vsetvl tests. Andrew's change slightly alters the branching structure of the code and that causes many of the vsetvl tests to go nuts since they require a specific set of instructio

[PATCH, 5/11] Add conversions between __bfloat16 and float/double.

This patch provides conversions between __bfloat16 and float/double scalars on power10 and power11 systems. Unlike the support for _Float16, there is not a single instruction to convert between a __bfloat16 and float/double scalar value on the power10. Instead we have to use the vector conversion

[PATCH, 6/11] Add conversions between 16-bit floating point and other scalar modes.

This patch adds convertions between _Float16/__bfloat16 and the other floating point and integer scalar types. It does this by doing the conversion to double as an intermediate type. All 11 patches have been tested on little endian and big endian PowerPC servers with no regressions. Can I check

Re: [PATCH 0/4] Implement hierarchical discriminators for AutoFDO

> On 15 Nov 2025, at 8:36 am, Kugan Vivekanandarajah > wrote: > > External email: Use caution opening links or attachments > > > Hi, > >>> >>> I think we want to solve two problems >>> 1) Handle situation when statement is duplicated (unrolling, loop >>> header copying etc.) and thus different

[PATCH v2 2/2] c: Reduce excess errors of _Maxof and _Minof

gcc/c/ChangeLog: * c-parser.cc (c_parser_maxof_or_minof_expression): After '(' has been parsed, if there's a syntax error, skip until ')', to minimize excess errors. gcc/testsuite/ChangeLog: * gcc.dg/maxof-compile.c (expr, specs): Update test. Signed-off-by: Alej

Re: [PATCH 0/4] Implement hierarchical discriminators for AutoFDO

> On 15 Nov 2025, at 8:36 am, Kugan Vivekanandarajah > wrote: > > External email: Use caution opening links or attachments > > > Hi, > >>> >>> I think we want to solve two problems >>> 1) Handle situation when statement is duplicated (unrolling, loop >>> header copying etc.) and thus diff

[PATCH, 4/11] Add conversions between _Float16 and float/double.

This patch adds support to generate xscvhpdp and xscvdphp on Power9 systems and later, to convert between _Float16 and float scalar values. All 11 patches have been tested on little endian and big endian PowerPC servers with no regressions. Can I check in these patches? 2025-11-14 Michael Meiss

Re: [PATCH 2/4] Implement hierarchical discriminators for AutoFDO

> On 15 Nov 2025, at 8:36 am, Kugan Vivekanandarajah > wrote: > > External email: Use caution opening links or attachments > > > Hi, > >>> >>> I think we want to solve two problems >>> 1) Handle situation when statement is duplicated (unrolling, loop >>> header copying etc.) and thus diff

[PATCH v2 0/2] c: Add _Maxof & _Minof [n3628, but rejecting _Bool]

Hi, Here's a second attempt at implementing these two operators. They're implemented as proposed in n3628, but differ slightly in that they reject _Bool (the first commit message details a bit more about this). I tested the feature while developing it, and those tests all passed. However, when I'

[PATCH, 2/11] Add initial 16-bit floating point support.

This patch adds the initial support for the 16-bit floating point formats. _Float16 is the IEEE 754 half precision format. __bfloat16 is the Google Brain 16-bit format. In order to use both _Float16 and __bfloat16, the user has to use the -mfloat16 option to enable the support. In this patch onl

[PATCH v2 1/2] c: Add _Maxof and _Minof operators

Link: This implementation differs from n3628 in that _Bool is not accepted by these operators in this implementation. It was an oversight to allow _Bool in n3628, and I will publish a revision of that paper with that amended, prior to t

[PATCH, 3/11] Add HF/BF emulation functions to libgcc.

>From 698a22ded27f3a1b85f496b2a30186994605 Mon Sep 17 00:00:00 2001 From: Michael Meissner Date: Fri, 14 Nov 2025 03:11:08 -0500 Subject: [PATCH 212/219] Add HF/BF emulation functions to libgcc. This patch adds the necessary support in libgcc to allow using the machine independent 16-bit floa

[PATCH, 1/11] Add infrastructure for _Float16 and __bfloat16 types.

This patch adds the infrastructure for adding 16-bit floating point types in the next patch. Two new types that will be added: _Float16 (HFmode): == This is the IEEE 754-2008 16-bit floating point. It has 1 sign bit, 5 exponent bits, 10 explicit mantassia bits (the 11th bit is i

[PATCH 1/4] Implement hierarchical discriminators for AutoFDO

> On 15 Nov 2025, at 8:36 am, Kugan Vivekanandarajah > wrote: > > External email: Use caution opening links or attachments > > > Hi, > >>> >>> I think we want to solve two problems >>> 1) Handle situation when statement is duplicated (unrolling, loop >>> header copying etc.) and thus diff

[PATCH] cobol: Fix bootstrap [PR122691]

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/cobol/lexio.cc:907:76: error: ‘%.*s’ directive argument is null [-Werror=for

[PATCH 0/4] Implement hierarchical discriminators for AutoFDO

Hi, >> >> I think we want to solve two problems >> 1) Handle situation when statement is duplicated (unrolling, loop >> header copying etc.) and thus different locations in program >> corresponds to different copies. >> >> Current code simply picks address with maximal count (expecting tha

[PATCH] c++: Implement part of CWG3044

Hi! The following patch implements part of CWG3044 resolution. Small part of it has been implemented already earlier (using ptrdiff_t as the type of i rather than leaving that unspecified), part of it can't be implemented until constexpr references are supported (removal of static keywords), but t

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

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 order or some other one. Bootstrapped/regtested on x86_64-linux and i686-

[PATCH, 0/11] Add PowerPC 16-bit experimental support

This series of 11 patches adds the preliminary support on PowerPC servers for 2 forms of 16-bit floating point. 1: _Float16 -- IEEE 754 16-bit floating point 2: __bfloat16 -- Google brain16 16-bit floating point This is only added on the little endian PowerPC servers that support ISA 2.08 (

[PATCH 5/5] arm: [MVE intrinsics] rework sqrshr sqshl srshr uqrshl uqshl urshr

Implement sqrshr, sqshl, srshr, uqrshl, uqshl and urshr using the new MVE builtins framework. The patch fixes a probable copy/paste typo in mve_sqshl_si and mve_srshr_si: operand 1 should have mode SI, and not DI. gcc/ChangeLog: * config/arm/arm-mve-builtins-base.cc (enum which_scalar_sh

[PATCH 1/5] arm: [MVE intrinsics] rework vpnot

Implement vpnot using the new MVE builtins framework. gcc/ChangeLog: * config/arm/arm-mve-builtins-base.cc (class mve_function_vpnot): New. (vpnot): New. * config/arm/arm-mve-builtins-base.def (vpnot): New. * config/arm/arm-mve-builtins-base.h (vpnot): New.

[PATCH 3/5] arm: [MVE intrinsics] rework sqrshrl sqrshrl_sat48

Implement sqrshrl and sqrshrl_sat48 using the new MVE builtins framework. gcc/ChangeLog: * config/arm/arm-mve-builtins-base.cc (enum which_scalar_shift): Add ss_SQRSHRL, ss_SQRSHRL_SAT48. (mve_function_scalar_shift): Add support for ss_SQRSHRL, ss_SQRSHRL_SAT48.

[PATCH 4/5] arm: [MVE intrinsics] rework sqshll srshrl uqshll urshrl

Implement sqshll, srshrl, uqshll and urshrl using the new MVE builtins framework. gcc/ChangeLog: * config/arm/arm-mve-builtins-base.cc (enum which_scalar_shift): Add ss_SQSHLL, ss_SRSHRL, ss_UQSHLL, ss_URSHRL. (mve_function_scalar_shift): Add support for ss_SQSHLL, ss_SRSHR

[PATCH 0/5] arm: [MVE intrinsics] rework vpnot and scalar shifts

This patch series is a subset of a series I posted previously, and was pre-approved by Richard as part of the MVE intrinsics re-implementation work. Pushed to trunk. Thanks, Christophe Christophe Lyon (5): arm: [MVE intrinsics] rework vpnot arm: [MVE intrinsics] rework uqrshll uqrshll_sat48

[PATCH 2/5] arm: [MVE intrinsics] rework uqrshll uqrshll_sat48

Implement uqrshll and uqrshll_sat48 using the new MVE builtins framework. gcc/ChangeLog: * config/arm/arm-mve-builtins-base.cc (enum which_scalar_shift): Add ss_UQRSHLL, ss_UQRSHLL_SAT48. (mve_function_scalar_shift): Add support for ss_UQRSHLL, ss_UQRSHLL_SAT48.

Re: [PATCH] libstdc++: Ensure that _Utf_view is always a view.

On Fri, 14 Nov 2025 at 18:04, Hewill Kang wrote: > > Thanks for the explanation. > During my review, I unexpectedly discovered that this UTF_view, which accepts > an input_range, doesn't consider the fact that the input_iterator only > guarantees that it can be moved. It uses copying in many pla

Re: [PATCH] Fortran: procedure targets in derived-type constructors [PR117070]

Am 14.11.25 um 01:29 schrieb Jerry D: All good, OK for mainline. Jerry Pushed as r16-5274-g4fa9ce0b7d1ac1 . Thanks for the review! Harald

[committed][wwwdocs] Fix a typo in the second floating-point argument register number

The second floating-point argument is passed in $f13 rather than $f14 as commit 1fcfc00d38ff ("Correct the MIPS O64 floating-point argument passing convention") incorrectly claimed. --- htdocs/projects/mipso64-abi.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/proj

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

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 pass to combat this. I have > added a knob on PHI-motion as I

Re: [PATCH] Add 'num_children' method to relevant pretty-printers

> ">" == Jonathan Wakely writes: > libstc++-v3/ChangeLog >> s/libstc++/libstdc++/ >> OK with that change (which would probably be caught by the receive hook >> anyway). Thanks, I'm checking it in now. Tom

[PATCH] RISC-V: -mmax-vectorization.

Hi, This adds an -mmax-vectorization option to riscv, copied verbatimly from aarch64 :) It is an option for vector code analysis. Internally it increases scalar costs by a large factor so every vector approach will be profitable. As opposed to -fno-vect-cost-model, we will still compare the vec

Re: [PATCH v2] c, plugin: Add c_parse_component_ref callback

On Thu, 2025-11-13 at 15:37 +0100, Jasper Niebuhr wrote: > I haven’t received input from any plugin experts yet. I tried to find > additional people to CC, but the MAINTAINERS file doesn’t list anyone > currently responsible for plugin-related areas. > > Though, to clarify: this patch does not mod

Re: [PATCH v5 2/2] aarch64: Add support for fmv priority syntax.

Hi Alfie,   > Adds support for the AArch64 fmv priority syntax. > > This allows users to override the default function ordering. LGTM, OK. Cheers, Wilco

[PATCH 2/4] Add publish/subscribe topics and channel: pass_events

This patch adds a new "struct compiler_channels" to hold channels relating to the compiler that plugins (or diagnostic sinks) might want to subscribe to events for, accessed from the global gcc::context object, along with a new gcc/topics/ source subdirectory to hold strongly-typed publish/subscrib

[PATCH 1/4] Add pub-sub.{h,cc}

This patch introduces a publish/subscribe mechanism, allowing for loosely-coupled senders and receivers, with strongly-typed messages passing between them. For example, a GCC subsystem could publish messages about events, and a plugin could subscribe to them. An example can be seen in the selftes

[PATCH 4/4] analyzer: replace PLUGIN_ANALYZER_INIT with a pub/sub channel

This patch eliminates the PLUGIN_ANALYZER_INIT event in favor of a new analyzer_events_channel that can be subscribed to, and ports all the in-tree analyzer plugins to using it. The PLUGIN_* approach isn't typesafe, and the name suggests it's only meant to be used for plugins, whereas the pub/sub

[PATCH 3/4] diagnostics: add optional CFG dumps to SARIF/HTML output sinks

This patch adds a new key/value pair "cfgs={yes,no}" to diagnostics sinks, "no" by default. If set to "yes" for a SARIF sink, then GCC will add the internal state of the CFG for all functions after each pertinent optimization pass in graph form to theRun.graphs in the SARIF output. If set to "yes

[PATCH 0/4] Publish/subscribe framework for typesafe loosely-coupled notifications

This patch kit introduces a publish/subscribe mechanism to GCC's codebase, allowing for loosely-coupled senders and receivers, with strongly-typed messages passing between them. For example, a GCC subsystem could publish messages about events, and plugins or diagnostic sinks could subscribe to the

Re: [PATCH] libstdc++: Optimize functor storage for transform views iterators.

We might also need is_default_constructible_v. For example, a singleton satisfies is_empty_v && copyable && trivially_copyable, but it is not a default-constructible. Otherwise, the forward iterator will not be default-constructible and will no longer be a forward iterator. I personally think that

Re: [PATCH] libstdc++: Ensure that _Utf_view is always a view.

Thanks for the explanation. During my review, I unexpectedly discovered that this UTF_view, which accepts an input_range, doesn't consider the fact that the input_iterator only guarantees that it can be moved. It uses copying in many places. Perhaps we should only accept forward_range. Or perhaps w

Re: [PATCH] libstdc++: Ensure that _Utf_view is always a view.

On Fri, Nov 14, 2025 at 6:55 PM Hewill Kang wrote: > LGTM. > > I know that CTAD wasn't provided due to heavy header considerations. But > wouldn't providing CTAD be an enhancement? > At least in terms of user convenience. > I care much more about the use of libstdc++ compile time performance, tha

Re: [PATCH] libstdc++: Ensure that _Utf_view is always a view.

LGTM. I know that CTAD wasn't provided due to heavy header considerations. But wouldn't providing CTAD be an enhancement? At least in terms of user convenience. Tomasz Kamiński 於 2025年11月15日 週六 上午1:06寫道： > Previously, _Utf_view accepted any input_range, including > reference-to-array > types li

Re: [PATCH v2] fold-mem-offsets: Convert from DF to RTL-SSA

On 11/14/25 10:19 AM, Andrew Pinski wrote: I am not sure this is a good idea if there is a known failure on some targets to enable it on other targets by default. Plus there is no analysis of the bootstrap failure to say if this is a bug in the backend or in the pass. If this was the beginni

[commited v2] libstdc++: Ensure that _Utf_view is always a view.

Previously, _Utf_view accepted any input_range, including reference-to-array types like char(&)[2], and stored it as the _M_base member. In such cases, _Utf_view was not assignable, failing the requirements of view concept. This patch addresses the issue by adding the ranges::view constraint to th

[PING^1][PATCH v2] docs: aarch64: arm: Update ACLE documentation.

Hi Alfie, LGTM, OK. Cheers, Wilco > Updates the Arm C Language Extension name, url and description to be up to > date. > > gcc/ChangeLog: > > * doc/extend.texi (ARM C Language Extensions (ACLE)): Change to... > (Arm C Language Extensions (ACLE)): ...this and update ACLE URL and >

[PATCH v2 1/2] aarch64: Add support for FEAT_PCDPHINT atomic_store intrinsics.

Hi Richard, I think there are some major issues with this. The key thing is that it needs to be type generic, and behave similarly to if you wrote *p = x; So that means you cannot use the type of expression 'x' and use that to determine the type of '*p'... I suggest you try a few cases like *char

[PATCH 6/6] RISC-V: Generic vec_set via subreg.

Similar to vec_extract this implements vec_sets that are present as subreg inserts. Similar to a single element we can just slide up a vector with the TU policy. gcc/ChangeLog: * config/riscv/riscv-v.cc (expand_vector_subreg_insert): New function. (legitimize_move): Use n

Re: [PATCH] libstdc++: Optimize functor storage for transform views iterators.

>From other side, it would be fairly easy to add another _TrivlalEmpty specialization for __func_handle, that would be generated under p3117r1 conditions, which I do not like, as they do not make even *it on same iterator sable for the Obfuscating symbol. I would go instead with is_empty_v && copya

[PATCH 5/6] RISC-V: Generic vec_extract via subreg.

We are missing several vec_extract chances because the current autovec patterns are not comprehensive. In particular we don't extract from pseudo-VLA modes that are actually VLS modes (just VLA modes in name). Rather than add even more mode combinations to vec_extract, this patch removes the expa

[PATCH 3/6] RISC-V: Add VLS modes to autovec iterators.

In order to allow more VLS vectorization, add more VLS modes to the autovec expanders, as well as some missing VLS modes that I encountered while testing. gcc/ChangeLog: * config/riscv/autovec.md: Ditto. * config/riscv/autovec-opt.md: Add VLS modes. * config/riscv/vector-c

[PATCH 4/6] RISC-V: Enable VLS select_vl loop control.

This patch enables VLS loops to be controlled by SELECT_VL/vsetvl. In case we choose a VLS mode for a loop we could only do fixed-size + epilogue before. With this patch such loops can be length controlled as well. As opposed to VLA length-controlled loops we need to make sure to not e --- gcc/c

[PATCH 1/6] RISC-V: Change gather/scatter iterators.

This patch changes the gather/scatter mode iterators from a ratio scheme to a more direct one where the index mode size is 1/2, 1/4, 1/8, 2, 4, 8 times the data mode size. It also adds VLS modes to the iterators and removes the now unnecessary gather_scatter_valid_offset_p. gcc/ChangeLog:

[PATCH 2/6] RISC-V: Rename vector-mode related functions.

This patch just performs renaming from e.g. riscv_v_ext_vector_mode_p to riscv_vector_mode_p and similar. gcc/ChangeLog: * config/riscv/riscv-avlprop.cc (pass_avlprop::execute): * config/riscv/riscv-protos.h (riscv_v_ext_vector_mode_p): (riscv_v_ext_tuple_mode_p): Rename

[PATCH 0/6] RISC-V: VLS related stuff.

This is not strictly a series but I'll still send it as such as all of them are loosely connected to more VLS enablement. The series is not clean and there is even one Fortran execution failure. I'll take care of that as well as the regressions still but wanted to get this out of the door during

Re: [PATCH] aarch64: Add cortex-A320 core

On Fri, Nov 14, 2025 at 5:45 AM Alfie Richards wrote: > > Hi All, > > This adds support for the Arm Cortex-A320 core > > Reg-tested on AArch64. > > Okay for master? > > Alfie > > -- >8 -- > > gcc/ChangeLog: > > * config/aarch64/aarch64-cores.def (cortex-a320): New core. > * config/

Re: [PATCH v2] fold-mem-offsets: Convert from DF to RTL-SSA

On Fri, Nov 14, 2025 at 6:30 AM Konstantinos Eleftheriou wrote: > > This patch converts the fold-mem-offsets pass from DF to RTL-SSA. > Along with this conversion, the way the pass collects information > was completely reworked. Instead of visiting each instruction multiple > times, this is now d

Re: [PATCH] libstdc++: Ensure that _Utf_view is always a view.

On Fri, 14 Nov 2025 at 17:05, Tomasz Kamiński wrote: > > Previously, _Utf_view accepted any input_range, including reference-to-array > types like char(&)[2], and stored it as the _M_base member. In such cases, > _Utf_view was not assignable, failing the requirement to be a view > concept. > > Thi

[PATCH v2 2/2] aarch64: Add support for __pldir intrinsic.

Hi Richard, > This patch adds support for the __pldir intrinsic. > This is a new prefetch intrinsic which declares an > intent to read from an address. > This intrinsic is part of FEAT_PCDPHINT. I wonder whether it would be easy to reuse more of the existing prefetch code, but this one is indeed

Re: [PATCH] fortran: correctly handle optional allocatable dummy arguments

Hi all, On Fri, Nov 14, 2025 at 6:19 PM Tobias Burnus wrote: > > Harald Anlauf wrote : > > Yuao Ma wrote: > >> … > > this is OK from my side. > > Likewise from my side, which makes it a double-approved patch :-) > Thanks for both reviews! Pushed as r16-5282-g14e5e4ee1ff4aa. Yuao

[PATCH] libstdc++: Ensure that _Utf_view is always a view.

Previously, _Utf_view accepted any input_range, including reference-to-array types like char(&)[2], and stored it as the _M_base member. In such cases, _Utf_view was not assignable, failing the requirement to be a view concept. This patch addresses the issue by adding the ranges::view constraint t

[RFC,PATCH] s390: Add HF mode support

Hi everyone, as promised in https://gcc.gnu.org/pipermail/gcc/2025-October/246854.html I would like to add _Float16 support to s390. I went for targetm.c.excess_precision(EXCESS_PRECISION_TYPE_FLOAT16) to return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 in order to stay for as long as possible in _Float

[PATCH 2/2] ia64: Expand MAX_VECT_LEN to 16

MAX_VECT_LEN is set to 8 on ia64, which is lower than on all other targets, where it is 16 at minimum. Some of the machine modes of ia64 are internally 16-byte wide, causing stringop-overflow to be unhappy when checking a loop in ia64_vectorize_vec_perm_const(). This causes bootstrap to fail. Mak

[PATCH 1/2] ia64: Fix zero_call_used_regs for PRs [PR121535]

ia64 uses default_zero_call_used_regs(), which uses emit_move_insn() to zero out registers. ia64 predicate registers use BImode, which is not supported by emit_move_insn(). Implement ia64_zero_call_used_regs() to zero PRs by manually emitting a CCImode move. default_zero_call_used_regs() is then c

[PATCH v1 1/1] aarch64: FEAT_SVE_BFSCALE support

Add support for the `SVE_BFSCALE` architecture extension. gcc/ChangeLog: * doc/invoke.texi: Document `+sve-bfscale` flag. * config/aarch64/aarch64-option-extensions.def (AARCH64_OPT_EXTENSION): New extension. * config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Ne

[PATCH v1 0/1] AArch64: SVE_BFSCALE support

Adds support for the SVE_BFSCALE feature, which provides the svscale and svmul intrinsics for BFloat16 vectors. Changelog: * V1: Initial version. Karl Meakin (1): aarch64: FEAT_SVE_BFSCALE support gcc/config/aarch64/aarch64-c.cc | 2 + .../aarch64/aarch64-option-extensions.d

  1   2   3   >