[PATCH] RISC-V: Add minimal support of double trap extension 1.0

Add support of double trap extension [1], enabling GCC to recognize the following extensions at compile time. New extensions: - ssdbltrp - smdbltrp [1] https://github.com/riscv/riscv-double-trap/releases/download/v1.0/riscv-double-trap.pdf gcc/ChangeLog: * config/riscv/riscv-ext.def

Re: [PATCH] libstdc++: Fix vector(from_range_t, R&&) for exceptions [PR120367]

On Wed, May 21, 2025 at 5:41 PM Jonathan Wakely wrote: > Because this constructor delegates to vector(a) the object has been > fully constructed and the destructor will run if an exception happens. > That means we need to set _M_finish == _M_start so that the destructor > doesn't try to destroy a

Re: [PATCH v2 1/6] libstdc++: Implement layout_left from mdspan.

On Wed, May 21, 2025 at 10:20 AM Luc Grosheintz wrote: > > > On 5/21/25 08:29, Tomasz Kaminski wrote: > > On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz > > > wrote: > > > >> Implements the parts of layout_left that don't depend on any of the > >> other layouts. > >> > >> libstdc++-v3/ChangeLog:

[PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32

Patch is originally from Siarhei Volkau . RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit pattern to recognize that we can store 0.0 into memory using x0 as the source

Re: [PATCH 2/2] aarch64: Fold lsl+lsr+orr to rev for half-width shifts

On 20/05/25 16:35, Richard Sandiford wrote: External email: Use caution opening links or attachments Dhruv Chawla writes: On 06/05/25 21:57, Richard Sandiford wrote: External email: Use caution opening links or attachments Dhruv Chawla writes: This patch modifies the intrinsic expanders

Re: Fix PR 118541, do not generate unordered fp cmoves for IEEE compares

I have posted a new version of the patch at: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684473.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com

Re: Fix PR 118541 (V6 not V3), do not generate unordered fp cmoves for IEEE compares

I got the version number of the patch wrong. This patch is something like V6 of the patch, not V3. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com

[PATCH v4 1/2] aarch64: Match unpredicated shift patterns for ADR, SRA and ADDHNB instructions

From: Dhruv Chawla This patch modifies the shift expander to immediately lower constant shifts without unspec. It also modifies the ADR, SRA and ADDHNB patterns to match the lowered forms of the shifts, as the predicate register is not required for these instructions. Bootstrapped and regtested

[PATCH v4 2/2] aarch64: Fold lsl+lsr+orr to rev for half-width shifts

From: Dhruv Chawla This patch folds the following pattern: lsl , , lsr , , orr , , to: revb/h/w , when the shift amount is equal to half the bitwidth of the register. Bootstrapped and regtested on aarch64-linux-gnu. Signed-off-by: Dhruv Chawla Co-authored-by: Richard Sandiford

Fix PR 118541 (V3), do not generate unordered fp cmoves for IEEE compares

Fix PR 118541, do not generate unordered fp cmoves for IEEE compares. This is version 3 of patch. I re-implemented the patch to just focus on the generation of the XSCMP{EQ,GT,GE}{DP,QP} instructions. In bug PR target/118541 on power9, power10, and power11 systems, for the function: ext

Re: [PATCH] testsuite: RISC-V: Update the cset-sext-sfb/zba-slliuw test optimization level.

Thanks. I will pay attention to this. Dongyan Chen 在 2025/5/22 11:49, Jeff Law 写道: On 5/21/25 9:16 PM, Dongyan Chen wrote: Failed testcases occurred in the regression test of gcc: cset-sext-sfb.c failed the -Oz test, and zba-slliuw.c failed the -Og test. This patch solves the problem by ski

Re: [PATCH] testsuite: RISC-V: Update the cset-sext-sfb/zba-slliuw test optimization level.

On 5/21/25 9:16 PM, Dongyan Chen wrote: Failed testcases occurred in the regression test of gcc: cset-sext-sfb.c failed the -Oz test, and zba-slliuw.c failed the -Og test. This patch solves the problem by skipping the optimization. gcc/testsuite/ChangeLog: * gcc.target/riscv/cset-sex

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 4/14/25 5:34 AM, Yangyu Chen wrote: On 14 Apr 2025, at 19:06, Alfie Richards wrote: Hi Yangyu, This looks great with what we discussed previously. I have a very similar patch that implements a slightly stronger optimisation that I was about to send. It makes use of information if th

[PATCH] testsuite: RISC-V: Update the cset-sext-sfb/zba-slliuw test optimization level.

Failed testcases occurred in the regression test of gcc: cset-sext-sfb.c failed the -Oz test, and zba-slliuw.c failed the -Og test. This patch solves the problem by skipping the optimization. gcc/testsuite/ChangeLog: * gcc.target/riscv/cset-sext-sfb.c: Skip for -Oz. * gcc.target/r

Re: [PATCH 2/4] c++/modules: Implement streaming of uncontexted TYPE_DECLs [PR98735]

On Thu, May 22, 2025 at 12:15:02PM +1000, Nathaniel Shead wrote: > Another approach would be to fix 'write_class_def' to handle these > declarations better, but that ended up being more work and felt fragile. > It also meant streaming a lot more information that we don't need. > > Long term I had

[PATCH 3/4] c++/modules: Support streaming new size cookie for constexpr [PR120040]

This type currently has a DECL_NAME of an IDENTIFIER_DECL. Although the documentation indicates this is legal, this confuses modules streaming which expects all RECORD_TYPEs to have a TYPE_DECL, which is used to determine the context and merge key, etc. PR c++/120040 gcc/cp/ChangeLog:

[PATCH 4/4] c++/modules: Avoid name clashes when streaming internal labels [PR98375,PR118904]

I'm not sure if there might be a better way to retrieve the prefix back off an IDENTIFIER_NODE? I'm also not sure if IDENTIFIER_INTERNAL_P could ever clash with IDENTIFIER_TRANSPARENT_ALIAS; I'm pretty sure not (and it looks like nothing ever sets that flag anyway, that I could find?) but would ap

[PATCH 2/4] c++/modules: Implement streaming of uncontexted TYPE_DECLs [PR98735]

Another approach would be to fix 'write_class_def' to handle these declarations better, but that ended up being more work and felt fragile. It also meant streaming a lot more information that we don't need. Long term I had been playing around with reworking ubsan.cc entirely to have a fixed set of

[PATCH 1/4] c++: Add flag to detect underlying representative of bitfield decls

This patch isn't currently necessary with how I've currently done the follow-up patches, but is needed for avoiding any potential issues in the future with DECL_CONTEXT'ful types getting created in the compiler with no names on the fields. (For instance, this change would make much of r15-7342-gd3

[PATCH 0/4] c++: Support modules streaming some internal structures with no DECL_CONTEXT

This patch series adds support for streaming some internal declarations in C++20 modules that we previously would ICE on. The series has been successfully bootstrapped and regtested on x86_64-pc-linux-gnu. Additionally, modules.exp now passes with '--target_board=unix/-fsanitize=undefined'. Na

Re: [RFC PATCH 0/3] _BitInt(N) support for LoongArch

On Wed, May 21, 2025 at 11:48:08AM GMT, Jakub Jelinek wrote: > In gimple-lower-bitint.cc I'd strongly prefer to differentiate between > changes required to get info->extended working correctly (that is what > should be committed first, and right now should include the LSHIFT_EXPR in > lower_shift_s

[PATCH 1/2] Support picolibc targets

Match *-picolibc-* and select picolibc as the default C library, plus continuing to use the newlib-based logic for other configuration items. Add custom spec file fragments for use with picolibc: * '--oslib='. Allows targets to insert an OS library after the C library in the LIB_PATH spec fil

Re: [PATCH] match: Undo maybe_push_res_to_seq in some cases [PR120331]

On 5/18/25 10:38 AM, Andrew Pinski wrote: While working on improving forwprop and removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison, I came cross a case where we end up with SSA_NAME in the resulting gimple_match_op and one statement in the sequence. This was the

[to-be-committed][RISC-V] Clear both upper and lower bits using 3 shifts

So the next step in Shreya's work. In the prior patch we used two shifts to clear bits at the high or low end of an object. In this patch we use 3 shifts to clear bits on both ends. Nothing really special here. With mvconst_internal still in the tree it's of marginal value, though Shreya an

[PATCH] configury: replace autoconf obsolete macros [PR/103459]

Autoreconf -Wall complains about obsolete macros, so replace them according to the autoconf documentation[0]. This patch doesn't fully fix all warnings because I focused on doing simple fixes and keeping the changes to the generated files to a minimum. Bootstrapped and retested on x86_64-linux-gn

[PATCH 0/2] Add picolibc support

The first patch in this series selects picolibc as the default C library when the target is *-picolibc-*. This configures the default compiler specs for picolibc usage, including the addition of three picolic-specific options. The section patch in this series allows the default C library to be sel

[PATCH 2/2] Allow default libc (either newlib or picolibc) to be specified to configure

The default C library is normally computed based on the target triplet. However, for embedded systems, it can be useful to leave the triplet alone while changing which C library is used by default. Other C libraries may still be available on the system so the compiler and can be used by specifying

RE: [PATCH] aarch64: Carry over zeroness in aarch64_evpc_reencode

> Pengxuan Zheng writes: > > There was a bug in aarch64_evpc_reencode which could leave zero_op0_p > > and zero_op1_p of the struct "newd" uninitialized. > > r16-701-gd77c3bc1c35e303 fixed the issue by zero initializing "newd." > > This patch provides an alternative fix as suggested by Richard > >

[PATCH v2] libstdc++: implement Philox Engine [PR119794]

Implements Philox Engine (P2075R6) and associated tests. v2 corrects a multiline comment left in error in serialize.cc, and additionally corrects a bug hidden by said comment, where the stream was given the output of 'y()' instead of 'y', causing state to be incorrectly passed. Lastly, it fixes

Re: [PATCH 1/2] expand: Use rtx_cost directly instead of gen_move_insn for canonicalize_comparison.

On 5/20/25 9:12 PM, Andrew Pinski wrote: This is the first part in fixing PR target/120372. The current code for canonicalize_comparison, uses gen_move_insn and rtx_cost to find out the cost of generating a constant. This is ok in most cases except sometimes the comparison instruction can han

Re: [AUTOFDO] Enable ipa-split for auto-profile

Ping? Thanks, Kugan > On 9 May 2025, at 11:55 am, Kugan Vivekanandarajah > wrote: > > ipa-split is not now run for auto-profile. IMO this was an oversight. > This patch enables it similar to PGO runs. > > gcc/ChangeLog: > >* ipa-split.cc pass_feedback_split_functions::clone (): New. >

Re: [AUTOFDO] Fix annotated profile for de-duplicated call

Ping? Thanks, Kugan > On 9 May 2025, at 11:51 am, Kugan Vivekanandarajah > wrote: > > External email: Use caution opening links or attachments > > > This patch fixes wrong annotation of profiles when call statement is > de-duplicated. i.e., when we may have same stmt executing from > more tha

Re: [AUTOFDO] Merge profiles of clones before annotating

Ping? Thanks, Kugan > On 9 May 2025, at 11:54 am, Kugan Vivekanandarajah > wrote: > > External email: Use caution opening links or attachments > > > This patch add support for merging profiles from multiple clones. > That is, when optimized binaries have clones such as IPA-CP clone or SRA > c

Re: [PATCH] configure: Always add pre-installed header directories to search path

On 9/25/24 9:22 PM, Stephanos Ioannidis wrote: configure script was adding the target directory flags, including the '-B' flags for the executable prefix and the '-isystem' flags for the pre-installed header directories, to the target flags only for non-Canadian builds under the premise that t

[PATCH v25 1/3] c: Add _Countof operator

This operator is similar to sizeof but can only be applied to an array, and returns its number of elements. FUTURE DIRECTIONS: - We should make it work with array parameters to functions, and somehow magically return the number of elements of the array, regardless of it being really a poin

[PATCH v25 3/3] c: Add -Wpedantic diagnostic for _Countof

It has been standardized in C2y. gcc/c/ChangeLog: * c-parser.cc (c_parser_sizeof_or_countof_expression): Add -Wpedantic diagnostic for _Countof in <= C23 mode. gcc/testsuite/ChangeLog: * gcc.dg/countof-compat.c: New test. * gcc.dg/countof-no-compat.c: New test.

[PATCH v25 2/3] c: Add

gcc/ChangeLog: * Makefile.in (USER_H): Add . * ginclude/stdcountof.h: New file. gcc/testsuite/ChangeLog: * gcc.dg/countof-stdcountof.c: New test. Signed-off-by: Alejandro Colomar --- gcc/Makefile.in | 1 + gcc/ginclude/stdcountof.h

[PATCH v25 0/3] c: Add _Countof and

Hi! Here's v25. Changes compared to v24 (see range-diff below): - Small fixes to the change logs. - Rewrap and remove parentheses in chains of ?: . - Implement c_parser_{sizeof,countof}_expression() as static inline. Tests still pass: $ grep countof ./gcc/testsuite/gcc/gcc.sum

Re: [PATCH] combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

On 5/21/25 4:29 PM, Andrew Pinski wrote: On Wed, May 21, 2025 at 3:21 PM Jeff Law wrote: On 5/5/25 3:27 PM, Andrew Pinski wrote: The problem here is simplify-rtx.cc expects gen_lowpart_no_emit to return NULL on failure but combine's hook was returning CLOBBER. After r16-160-ge6f89d78c1a7

Re: [PATCH] combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

On 5/5/25 3:27 PM, Andrew Pinski wrote: The problem here is simplify-rtx.cc expects gen_lowpart_no_emit to return NULL on failure but combine's hook was returning CLOBBER. After r16-160-ge6f89d78c1a7528e93458278, gcc.target/i386/avx512bw-pr103750-2.c started to fail at -m32 due to this as new

Re: [PATCH] combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

On Wed, May 21, 2025 at 3:21 PM Jeff Law wrote: > > > > On 5/5/25 3:27 PM, Andrew Pinski wrote: > > The problem here is simplify-rtx.cc expects gen_lowpart_no_emit > > to return NULL on failure but combine's hook was returning CLOBBER. > > After r16-160-ge6f89d78c1a7528e93458278, > > gcc.target/i

[to-be-committed][RISC-V] Clear high or low bits using shift pairs

So the first special case of clearing bits from Shreya's work. We can clear an arbitrary number of high bits by shifting left by the number of bits to clear, then logically shifting right to put everything in place. Similarly we can clear an arbitrary number of low bits with a right logica

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

On Wed, May 21, 2025 at 11:44:42PM +0200, Alejandro Colomar wrote: > Does this sound good? > > diff --git i/gcc/c/c-parser.cc w/gcc/c/c-parser.cc > index faa03c4903a2..733cb312341e 100644 > --- i/gcc/c/c-parser.cc > +++ w/gcc/c/c-parser.cc > @@ -78,16 +78,6 @@ along w

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/20/25 1:56 PM, Robin Dapp wrote: Maybe I'm missing something there.  Particularly whether or not you can know anything about frm's value after a call has returned. Normally the answer to this kind of question is a hard no. AFAICT the main difference to standard mode switching is that

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

Hi Jakub, On Wed, May 21, 2025 at 11:47:30PM +0200, Jakub Jelinek wrote: > > @@ -1747,6 +1737,8 @@ static struct c_expr c_parser_binary_expression > > (c_parser *, struct c_expr *, > > tree); > > static struct c_expr c_parser_cast_expr

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

Hi Jakub, On Wed, May 21, 2025 at 11:31:05PM +0200, Alejandro Colomar wrote: > > > +#define c_parser_sizeof_expression(parser) > > > \ > > > +( > > > \ > > > + c_parser_sizeof_or_count

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

On Wed, May 21, 2025 at 11:31:01PM +0200, Alejandro Colomar wrote: > The preexisting ones are not just the outermost ones. The preexisting > code was > > (in_sizeof >? "sizeof" >: (in_typeof ? "typeof" : "alignof"))); > > The only pattern I can find

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

On Wed, May 21, 2025 at 11:36:56PM +0200, Alejandro Colomar wrote: > Hi Jakub, > > On Wed, May 21, 2025 at 11:12:07PM +0200, Jakub Jelinek wrote: > > > warning_at (loc, OPT_Wc___compat, > > > "defining type in %qs expression is invalid in C++", > > > (in_sizeof > > >

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

Hi Jakub, On Wed, May 21, 2025 at 11:12:07PM +0200, Jakub Jelinek wrote: > > warning_at (loc, OPT_Wc___compat, > > "defining type in %qs expression is invalid in C++", > > (in_sizeof > > ? "sizeof" > > -: (in_typeof ? "typeof" : "alignof"))); >

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

Hi Jakub, On Wed, May 21, 2025 at 11:12:07PM +0200, Jakub Jelinek wrote: > > * c-common.h: Add RID_COUNTOF. > > (enum rid): Add RID_COUNTOF. Okay. > > > (c_countof_type): New function prototype. > > * c-common.def (COUNTOF_EXPR): New tree. > > * c-common.cc > > (c_common_re

Re: [PATCH v24 3/3] c: Add -Wpedantic diagnostic for _Countof

On Wed, May 21, 2025 at 11:01:38PM +0200, Alejandro Colomar wrote: > It has been standardized in C2y. > > gcc/c/ChangeLog: > > * c-parser.cc (c_parser_sizeof_or_countof_expression): > Add -Wpedantic diagnostic for _Countof in <= C23 mode. > > gcc/testsuite/ChangeLog: > > * gcc

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

On Wed, May 21, 2025 at 11:01:31PM +0200, Alejandro Colomar wrote: > This operator is similar to sizeof but can only be applied to an array, > and returns its number of elements. > > FUTURE DIRECTIONS: > > - We should make it work with array parameters to functions, >and somehow magically re

Re: [PATCH v24 2/3] c: Add

On Wed, May 21, 2025 at 11:01:35PM +0200, Alejandro Colomar wrote: > gcc/ChangeLog: > > * Makefile.in (USER_H): Add . > * ginclude/stdcountof.h: Add countof macro. This one is actually : New file. If the header existed before and you've just added countof macro definition, it would be

[PATCH v24 2/3] c: Add

gcc/ChangeLog: * Makefile.in (USER_H): Add . * ginclude/stdcountof.h: Add countof macro. gcc/testsuite/ChangeLog: * gcc.dg/countof-stdcountof.c: Add tests for . Signed-off-by: Alejandro Colomar --- gcc/Makefile.in | 1 + gcc/ginclude/stdcount

[PATCH v24 1/3] c: Add _Countof operator

This operator is similar to sizeof but can only be applied to an array, and returns its number of elements. FUTURE DIRECTIONS: - We should make it work with array parameters to functions, and somehow magically return the number of elements of the array, regardless of it being really a poin

[PATCH v24 3/3] c: Add -Wpedantic diagnostic for _Countof

It has been standardized in C2y. gcc/c/ChangeLog: * c-parser.cc (c_parser_sizeof_or_countof_expression): Add -Wpedantic diagnostic for _Countof in <= C23 mode. gcc/testsuite/ChangeLog: * gcc.dg/countof-compat.c: Test _Countof diagnostics with -Wc23-c2y-compat on

[PATCH v24 0/3] c: Add _Countof and

Hi! Here's v24. Changes compared to v23 (see range-diff below): - Use a GNU dialect in tests that use GNU extensions. - Add comment about the syntax of _Countof. Tests still pass: $ grep countof ./gcc/testsuite/gcc/gcc.sum PASS: gcc.dg/countof-compat.c (test for warnings, li

[to-be-committed][RISC-V] Improve (x << C1) + C2 split code

I wrote this a couple months ago to fix an instruction count regression in 505.mcf on risc-v, but I don't have a trivial little testcase to add to the suite. There were two problems with the pattern. First, the code was generating a shift followed by an add after reload. Naturally combine doe

Re: [PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32

On 5/21/25 12:20 PM, Shreya Munnangi wrote: Patch is originally from Siarhei Volkau >. RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit

[PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32

Patch is originally from Siarhei Volkau . RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit pattern to recognize that we can store 0.0 into memory using x0 as the source

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

On 5/20/25 4:05 PM, 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 vsetvli a5,a1,e32,m1,tu,ma vle32.v v2,

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

On 5/20/25 4:05 PM, 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 vsetvli a5,a1,e32,m1,tu,ma vle32.v v2,

Re: [PATCH 2/2] RISC-V:Add testcases for signed .SAT_ADD IMM form 1 with IMM = -1.

On 5/20/25 8:39 PM, Li, Pan2 wrote: Thanks Jeff. So for the tests, why are we forcing matching of the assembly code for the entire function? That must makes for a fragile test as we may change various aspects of code generation over time. If the point of the patch is to detect SAT_ADD in

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

On Wed, 21 May 2025, Alejandro Colomar wrote: > Makes sense. I'm unsure where exactly I should put it. Is this okay? > > diff --git i/gcc/c/c-parser.cc w/gcc/c/c-parser.cc > index 87700339394b..08350a216dd8 100644 > --- i/gcc/c/c-parser.cc > +++ w/gcc/c/c-parser.cc >

[PATCH] testsuite: Fix typo in parse_ctx.cc

libstdc++-v3/ChangeLog: * testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard. --- Ok for mainline? libstdc++-v3/testsuite/std/format/parse_ctx.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc b/libstdc++-v

[to-be-committed][RISC-V][PR target/120368] Fix 32bit shift on rv64

So a followup to last week's bugfix. In last week's change we we stopped using define_insn_and_split to rewrite instructions. That change was done to avoid dropping a masking instruction out of the RTL. As a result the pattern(s) were changed into simple define_insns, which is good. One of

Re: [PATCH] c++: substituting fn parm redeclared with dep alias tmpl [PR120224]

On 5/20/25 11:28 AM, Patrick Palka wrote: On Mon, 19 May 2025, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/15/14? Whoops, CI reports I missed a testsuite adjustment expecting an additional error in other/default13.C, which seems reasonab

Re: [PATCH] libstdc++: Fix vector(from_range_t, R&&) for exceptions [PR120367]

On Wed, 21 May 2025, Jonathan Wakely wrote: > Because this constructor delegates to vector(a) the object has been > fully constructed and the destructor will run if an exception happens. > That means we need to set _M_finish == _M_start so that the destructor > doesn't try to destroy any elements.

Re: [PATCH] libstdc++: Make debug iterator pointer sequence const [PR116369]

Sending again because my previous reply got a weird 'Got' word as its header that might be making it looks like a mistake. On 14/05/2025 18:46, Jonathan Wakely wrote: On Wed, 14 May 2025 at 17:31, François Dumont wrote: On 12/05/2025 23:03, Jonathan Wakely wrote: On 31/03/25 22:20 +0200, Fra

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

Hi Joseph, On Wed, May 21, 2025 at 04:26:46PM +, Joseph Myers wrote: > On Wed, 21 May 2025, Alejandro Colomar wrote: > > > @@ -10572,6 +10583,8 @@ c_parser_unary_expression (c_parser *parser) > > case CPP_KEYWORD: > >switch (c_parser_peek_token (parser)->keyword) > > { > > +

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

On Wed, 21 May 2025, Alejandro Colomar wrote: > @@ -10572,6 +10583,8 @@ c_parser_unary_expression (c_parser *parser) > case CPP_KEYWORD: >switch (c_parser_peek_token (parser)->keyword) > { > + case RID_COUNTOF: > + return c_parser_countof_expression (parser); > c

Re: [PATCH] Match: Handle commonly used unsigned modulo counters

Dear Richard, Thank you so much for your reply. I submitted the patch for the third case to LLVM before I've received your reply, and they said the same thing, that it would probably be used outside of loops as well and it would inflict a branch misprediction, so it should be implemented at the le

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

On Wed, 21 May 2025, Christopher Bazley wrote: > Would you agree this is adequate? If anyone wants different source code > locations to be highlighted then a future commit could change that. In this case the locations seem reasonable. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] RISC-V: Add autovec mode param.

Could you make a simple testcase that could vectorize two loops in different modes (e.g one SI and one SF) and with this param will only auto vec on loop? I added a test now in the attached v2 that checks that we vectorize with the requested mode. Right now the patch only takes away "additiona

[PATCH] libstdc++: Fix vector(from_range_t, R&&) for exceptions [PR120367]

Because this constructor delegates to vector(a) the object has been fully constructed and the destructor will run if an exception happens. That means we need to set _M_finish == _M_start so that the destructor doesn't try to destroy any elements. libstdc++-v3/ChangeLog: PR libstdc++/12036

[PATCH v4 1/1] Add warnings of potentially-uninitialized padding bits

Commit 0547dbb725b reduced the number of cases in which union padding bits are zeroed when the relevant language standard does not strictly require it, unless gcc was invoked with -fzero-init-padding-bits=unions or -fzero-init-padding-bits=all in order to explicitly request

[PATCH v4 0/1] Add warnings of potentially-uninitialized padding bits

Commit 0547dbb725b reduced the number of cases in which union padding bits are zeroed when the relevant language standard does not strictly require it, unless gcc was invoked with -fzero-init-padding-bits=unions or -fzero-init-padding-bits=all in order to explicitly request zeroing of padding bits.

Re: [PATCH v3 0/9] Implement layouts from mdspan.

It's missing the "registration" of the three new classes in std.cc.in. On 5/21/25 11:40, Luc Grosheintz wrote: Follows up on: https://gcc.gnu.org/pipermail/libstdc++/2025-May/061535.html To improve naming conventions, this series includes three new commits: * Two commits to rename _ExtentsS

Re: [PATCH] RISC-V: Support CPUs in -march.

On Wed, May 21, 2025 at 10:19 PM Robin Dapp wrote: > > > I could imagine that is a simpler way to set the march since the march > > string becomes terribly long - we have an arch string more than 300 > > char...so I support this, although I think this should be discuss with > > LLVM community, but

Re: [PATCH] RISC-V: Support CPUs in -march.

I could imagine that is a simpler way to set the march since the march string becomes terribly long - we have an arch string more than 300 char...so I support this, although I think this should be discuss with LLVM community, but I think it's fine to accept as a GCC extension. So LGTM, go ahead t

Re: [PATCH] RISC-V: Add autovec mode param.

Could you make a simple testcase that could vectorize two loops in different modes (e.g one SI and one SF) and with this param will only auto vec on loop? On Wed, May 21, 2025 at 9:47 PM Robin Dapp wrote: > > Hi, > > This patch adds a --param=autovec-mode=. When the param is > specified we make

Re: [PATCH] RISC-V: Support CPUs in -march.

I could imagine that is a simpler way to set the march since the march string becomes terribly long - we have an arch string more than 300 char...so I support this, although I think this should be discuss with LLVM community, but I think it's fine to accept as a GCC extension. So LGTM, go ahead to

Re: [PATCH] RISC-V: Default-initialize variable.

LGTM On Wed, May 21, 2025 at 9:49 PM Robin Dapp wrote: > > Hi, > > this patch initializes saved_vxrm_mode to VXRM_MODE_NONE. This is a > warning (but no error) when building the compiler so better fix it. > > Regtested on rv64gcv_zvl512b. Going to commit as obvious if the CI > is happy. > > Reg

[PATCH] RISC-V: Support CPUs in -march.

Hi, This patch allows an -march string like -march=sifive-p670 in order to allow overriding a previous -march in a simple way. Suppose we have a Makefile that specifies -march=rv64gc by default. A user-specified -mcpu=sifive-p670 would be after the -march in the options string and thus only s

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

Hi Jakub, Thanks for your review. On 21/05/2025 13:51, Jakub Jelinek wrote: On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote: On 21/05/2025 12:26, Christopher Bazley wrote: Hi Joseph, Thanks for reviewing my patch. On 20/05/2025 18:02, Joseph Myers wrote: On Tue, 20 May 2

[PATCH] RISC-V: Default-initialize variable.

Hi, this patch initializes saved_vxrm_mode to VXRM_MODE_NONE. This is a warning (but no error) when building the compiler so better fix it. Regtested on rv64gcv_zvl512b. Going to commit as obvious if the CI is happy. Regards Robin gcc/ChangeLog: * config/riscv/riscv.cc (singleton_vx

[PATCH] RISC-V: Add autovec mode param.

Hi, This patch adds a --param=autovec-mode=. When the param is specified we make autovectorize_vector_modes return exactly this mode if it is available. This helps when testing different vectorizer settings. Regtested on rv64gcv_zvl512b. Regards Robin gcc/ChangeLog: * config/riscv/r

Re: [PATCH 3/3] genemit: Use a byte encoding to generate insns

On 5/21/25 5:06 AM, Richard Sandiford wrote: Jeff Law writes: Given you know the RTL gen* related thingies better than anyone, I'd say go forward and if there's any fallout, we can certainly cope with it. Thanks. I've now pushed the series and the earlier genemit tweaks, with the discusse

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote: > On 21/05/2025 12:26, Christopher Bazley wrote: > > Hi Joseph, > > > > Thanks for reviewing my patch. > > > > On 20/05/2025 18:02, Joseph Myers wrote: > > > On Tue, 20 May 2025, Christopher Bazley wrote: > > > > > > > +    if (

[PATCH v3 0/1] Add warnings of potentially-uninitialized padding bits

Commit 0547dbb725b reduced the number of cases in which union padding bits are zeroed when the relevant language standard does not strictly require it, unless gcc was invoked with -fzero-init-padding-bits=unions or -fzero-init-padding-bits=all in order to explicitly request zeroing of padding bits.

[PATCH v3 1/1] Add warnings of potentially-uninitialized padding bits

Commit 0547dbb725b reduced the number of cases in which union padding bits are zeroed when the relevant language standard does not strictly require it, unless gcc was invoked with -fzero-init-padding-bits=unions or -fzero-init-padding-bits=all in order to explicitly request

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

On 21/05/2025 12:26, Christopher Bazley wrote: Hi Joseph, Thanks for reviewing my patch. On 20/05/2025 18:02, Joseph Myers wrote: On Tue, 20 May 2025, Christopher Bazley wrote: +    if (!cleared) +  { +    if (complete_p.padded_non_union +    && warn_zero_init_padding_bits >= ZER

Re: [PATCH] i386, v2: Extend *cmp_minus_1 optimizations also to plus with CONST_INT [PR120360]

On Wed, May 21, 2025 at 1:20 PM Jakub Jelinek wrote: > > On Wed, May 21, 2025 at 11:48:34AM +0200, Uros Bizjak wrote: > > Please introduce "x86_64_neg_const_int_operand" predicate that will > > allow only const_int operands, and will reject negative endbr (and > > wide DImode) const_ints. You don'

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

Hi Joseph, Thanks for reviewing my patch. On 20/05/2025 18:02, Joseph Myers wrote: On Tue, 20 May 2025, Christopher Bazley wrote: + if (!cleared) + { + if (complete_p.padded_non_union + && warn_zero_init_padding_bits >= ZERO_INIT_PADDING_BITS_ALL) +

[PATCH] i386, v2: Extend *cmp_minus_1 optimizations also to plus with CONST_INT [PR120360]

On Wed, May 21, 2025 at 11:48:34AM +0200, Uros Bizjak wrote: > Please introduce "x86_64_neg_const_int_operand" predicate that will > allow only const_int operands, and will reject negative endbr (and > wide DImode) const_ints. You don't need a constraint if the predicate > allows only const_ints (t

Re: [PATCH 3/3] genemit: Use a byte encoding to generate insns

Jeff Law writes: > Given you know the RTL gen* related thingies better than anyone, I'd say > go forward and if there's any fallout, we can certainly cope with it. Thanks. I've now pushed the series and the earlier genemit tweaks, with the discussed change to mark the operandN arguments as cons

[PATCH v3 2/2] gimple-fold: extend vector simplification to match scalar bitwise optimizations [PR119196]

Generalize existing scalar gimple_fold rules to apply the same bitwise comparison simplifications to vector types. Previously, an expression like (x < y) && (x > y) would fold to `false` if x and y are scalars, but equivalent vector comparisons were left untouched. T

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Hi, Yuao Ma wrote: I'm pretty swamped for the next couple of days Same issue here - hence, I haven't completed the review ... You're absolutely right that the best way to keep changes minimal is to just rename the `*resolve*` function. I missed the -gfc_resolve_trigd, +gfc_resolve_trig, c

[PATCH v3 0/2] tree-optimization: extend scalar comparison folding to vectors [PR119196]

New in V3: Added XOR comparison optimization with the appropriate tests. Any further optimizations involving scalars are left for a future, separate patch, as these may be considered outside the scope of Bug 119196, whose focus was on missed folding of vector comparisons. -

[PATCH v3 1/2] tree-simplify: unify simple_comparison ops in vec_cond for bit and/or/xor [PR119196]

Merge simple_comparison patterns under a single vec_cond_expr for bit_and, bit_ior, and bit_xor in the simplify pass. Ensure that when both operands of a bit_and, bit_or, or bit_xor are simple_comparison results, they reside within the same vec_cond_expr rather than separate ones. This prepares t

  1   2   >