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

Same style error. On 6/4/25 16:58, 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 should tr

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

If not committed yet, there's a style error, see below. On 6/4/25 16:58, 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):

Re: [PATCH] libfortran: Add script to regenerate source files

Hi FX, the patch looks good to me. I only have x86_64, too, therefore I haven't tested it (again). There's a lot of repetition in the regenerate.sh file. I hope to see this "simplified" or rather DRY'ed (Don't repeat yourself - principle) in the future. So looks good to me. Ok for mainline. Rega

Re: [PATCH] doc: allow extend.texi to be processed by makeinfo 4.13

On 06.06.2025 17:28, Sandra Loosemore wrote: > On 6/6/25 00:44, Jan Beulich wrote: >> As per documentation, even 4.7 ought to suffice. At least 4.13 objects >> to there being nothing ahead of the first comma in @xref{}. >> --- >> The text inserted it merely a guess; I'm open to better suggestions.

[wwwdocs, committed] gcc-16/changes.html + projects/gomp/: OpenMP/OpenACC update

First real entries for https://gcc.gnu.org/gcc-16/changes.html New API routines for OpenMP and OpenACC Added one supported and one partial to https://gcc.gnu.org/projects/gomp/ (Once a bit more is implemented, the partial one [declare mapper] will be also be added to gcc-16/changes.html and libgo

[PATCH] driver: Try to read spec from gcc_exec_prefix if possible

GCC will try to read the spec file from the directory where it is installed, but it should try to read from gcc_exec_prefix rather than standard_exec_prefix, because the latter is not the right one if compiler has been relocated into other places other than the path specfied at configuration time.

[PATCH] libstdc++: Make __max_size_type and __max_diff_type structural

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This patch makes these integer-class types structural types by public-izing their data memberss so that they could be used as NTTP types. I don't think the standard requires this, but it seems like a useful extension. libstdc+

[committed] RISC-V: Regen riscv-ext.texi [NFC]

Regenerates the `riscv-ext.texi` file in the GCC documentation. gcc/ChangeLog: * doc/riscv-ext.texi: Regen. --- gcc/doc/riscv-ext.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/riscv-ext.texi b/gcc/doc/riscv-ext.texi index e69a2df768d..c3ed1bfb593 100644

Re: [PATCH] [AUTOFDO] Don't scale bb_count with ipa_count when ipa_count is zero but count_max is not

Ping On Mon, May 19, 2025 at 10:06 AM liuhongt wrote: > > From: "hongtao.liu" > > AutoFDO profile is a scaled profile, as a result, 0 sample does not > mean never executed. especially there's profile from function > body. Prevent combine_with_ipa_count·(ipa_count) from zeroing all > bb->count. >

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

Hi, On Thu, 22 May 2025, 1nfocalypse wrote: > 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', c

[PATCH] c, c++: Fix unused result for empty types [PR82134]

Hi, This fixes PR c/82134 which concerns gcc emitting an incorrect unused result diagnostic for empty types. This diagnostic is emitted from tree-cfg.cc because of a couple code paths which attempt to avoid copying empty types, resulting in GIMPLE that isn't using the returned value of a call. To f

[PATCH 2/2] libstdc++: Directly implement ranges::sort [PR100795]

As with the previous patch, this patch reimplements ranges::sort directly instead of incorrectly forwarding to std::sort. In addition to the compatibility changes listed in the previous patch we also: - use ranges::iter_swap instead of std::iter_swap - use ranges::move_backward instead of std

[PATCH 1/2] libstdc++: Directly implement ranges::heap algos [PR100795]

ranges::push_heap, ranges::pop_heap, ranges::make_heap and ranges::sort_heap are currently defined in terms of the corresponding STL-style algorithms, but this is incorrect because the STL-style algorithms rely on the legacy iterator system, and so misbehave when passed a narrowly C++20 random acce

Re: [PATCH] forwprop: Change optimize_agr_copyprop into forward walk instead of backwards

On Mon, Jun 9, 2025 at 2:49 AM Richard Biener wrote: > > On Sun, Jun 8, 2025 at 7:52 PM Andrew Pinski wrote: > > > > While thinking about how to implement the rest of the copy prop and makes > > sure not > > to introduce some compile time problems, optimize_agr_copyprop should be > > changed >

Re: [RFC PATCH v2] cselib: Reuse VALUEs on reg adjustments

On 12/3/24 9:57 PM, Bohan Lei wrote: This is v2 of the patch in https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669380.html. I missed the ChangeLog entry in that version. The commit 2c0fa3ecf70d199af18785702e9e0548fd3ab793 reuses VALUEs on sp adjustments. We can generalize the idea a

Re: [PATCH] RISC-V: Add 'bclr+binv' peephole2 optimization.

On 6/5/25 6:25 AM, Jiawei wrote: Thanks for your suggestions, I found that the ior is successful generated in combine pass without using the zbs extension, and in other architecture it also work fine. Yea, it's probably an artifact of how we need to represent the single bit clear. It's r

Re: [PATCH v5 11/24] Add clone_identifier function.

On 5/29/25 6:46 AM, Alfie Richards wrote: This is similar to clone_function_name and its siblings but takes an identifier tree node rather than a function declaration. This is to be used in conjunction with the identifier node stored in cgraph_function_version_info::assembler_name to mangle F

Re: [PATCH v5 06/24] Refactor record_function_versions.

On 5/29/25 6:46 AM, Alfie Richards wrote: Renames record_function_versions to add_function_version, and make it explicit that it is adding a single version to the function structure. Additionally, change the insertion point to always maintain priority ordering of the versions. This allows fo

[PATCH] gcc: Make int n_infiles local to gcc.cc.

In the course of stamping out cppcheck warnings, we ran across a complaint about a "shadowed variable." It turns out that a variable declared in gcc/gcc/h as "extern int n_infiles;" is used only locally in gcc/gcc/cc. This change makes that variable "static int n_infiles;" in gcc/gcc.cc. Okay fo

[to-be-committed][RISC-V] Fix ICE due to splitter emitting constant loads directly

This is a fix for a bug found internally in Ventana using the cf3 testsuite. cf3 looks to be dead as a project and likely subsumed by modern fuzzers. In fact internally we tripped another issue with cf3 that had already been reported by Edwin with the fuzzer he runs. Anyway, the splitter in

Re: [wwwdocs] Add C status page (check, small tweaks)

On Mon, 9 Jun 2025, Marek Polacek wrote: > I've checked our C99 status table against the list in Annex M.5 in C23 > (n3220). > I found no issues. For this it probably makes sense to refer to the latest C2y draft, but there shouldn't be any significant changes to the pre-C23 lists there. (C2y

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

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_replaceable) and there are jus

Re: [PATCH 3/3] c: Add remove_qualifier helper function [PR120510]

On Sat, 7 Jun 2025, Martin Uecker wrote: > Add a helper function to replace repeated code for removing > qualifiers but not atomic. Make sure to also remove qualifiers > but not atomic on the element type of arrays. > > PR c/120510 > > gcc/c/ChangeLog: > * c-typeck.c (remove_qualifi

Re: [PATCH 2/3] c: partial fix for qualifier inconsistency II [PR120510]

On Sat, 7 Jun 2025, Martin Uecker wrote: > This fixes a case where we invoke composite_type with types > that do not have matching qualifiers. With this change, we can > activate the checking assertion that makes sure the composite > type is compatible with the two original types also for arrays.

Re: [PATCH 1/3] c: partial fix for qualifier inconsistency [PR120510]

On Sat, 7 Jun 2025, Martin Uecker wrote: > Checking assertion revealed that we sometimes produce > composite types with incorrect qualifiers, e.g. the example > > int f(int [_Atomic]); > int f(int [_Atomic]); > int f(int [_Atomic]); > > was rejected because atomic was lost in the second declarat

Re: [PATCH v2 1/2] emit-rtl: Allow extra checks for paradoxical subregs [PR119966]

On Mon, Jun 09, 2025 at 12:21:16PM -0600, Jeff Law wrote: > > > On 6/9/25 9:43 AM, Stafford Horne wrote: > > > > > Hi, > > > > I do not have a fix for this yet. I feel using or1k_hard_regno_mode_ok to > > control allowing paradoxical subreging of openriscs sr_f special register > > is not >

Re: [PATCH v2 1/2] emit-rtl: Allow extra checks for paradoxical subregs [PR119966]

On Mon, Jun 09, 2025 at 04:42:49PM +0100, Richard Sandiford wrote: > Stafford Horne writes: > > On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote: > >> On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote: > >> > Stafford Horne writes: > >> > > Hello, > >> > > > >> > > T

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

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 that onto the outlined body. This was no

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

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 trunk? thanks Iain --- 8< --- Here we

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

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 account for await expressions in that loweri

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

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 added here. gcc/cp/ChangeLog: *

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

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 places to cleanup was probably a design fl

[wwwdocs] Add C status page (check, small tweaks)

I've checked our C99 status table against the list in Annex M.5 in C23 (n3220). I found no issues. This patch renames the title of our C status page in preparation for adding C11 and C23 lists. W3 validated. Ok? --- htdocs/projects/c-status.html | 27 --- 1 file changed

[PATCH v2] c++, coroutines: Improve diagnostics for awaiter/promise.

Hi Jason, >>+ error_at (loc, "%sawaitable type %qT is not a structure", >>+ extra, o_type); >Generally identifiers should be incorporated with %qs, and relying on the %s >to provide a space doesn't seem very i8n-friendly. Better, I think, to handle >the case with no identifier

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

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 the closing brace for code that represen

[PATCH] or1k: Fix ICE in libgcc caused by recent validate_subreg changes

After commit eb2ea476db2 ("emit-rtl: Allow extra checks for paradoxical subregs [PR119966]") paradoxical subregs or the OpenRISC condition flag register (reg:BI sr_f) are no longer allowed. This causes and ICE in the ce1 pass which tries to get the or1k flag register into an SI register, which is

[PATCH] libfortran: Add script to regenerate source files

Hi, This patch adds a new “regenerate.sh” script in libgfortran/, which is the new mechanism to rebuild all source files in the generated/ folder. It removes this from the Makefile (where it was misusing the maintainer mode, which was not intended for that purpose). The new script is standalone

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

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_subreg. > > > > The simplify_su

[pushed: r16-1348] diagnostics: convert enum logical_location_kind to enum class

No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r16-1348-gbf0c6e1d34fd9c. gcc/ChangeLog: * diagnostic-format-sarif.cc (maybe_get_sarif_kind): Update for conversion of enum logical_location_kind to enum class.

Re: [PATCH v2 1/2] emit-rtl: Allow extra checks for paradoxical subregs [PR119966]

On 6/9/25 9:43 AM, Stafford Horne wrote: Hi, I do not have a fix for this yet. I feel using or1k_hard_regno_mode_ok to control allowing paradoxical subreging of openriscs sr_f special register is not right. It seems we would want to have something like or1k_regno_paradoxical_subreg_mode_

Re: [PATCH v6 1/3][Middle-end] Provide more contexts for -Warray-bounds, -Wstringop-*warning messages due to code movements from compiler transformation (Part 1) [PR109071,PR85788,PR88771,PR106762,PR1

> On Jun 6, 2025, at 03:31, Richard Biener wrote: > > On Fri, May 30, 2025 at 5:13 PM Qing Zhao wrote: >> >> Hi, Richard, >> >> Really appreciate for your suggestions. >> >>> On May 30, 2025, at 05:22, Richard Biener >>> wrote: >>> >>> On Fri, May 23, 2025 at 10:49 PM Qing Zhao wrote: >

Re: [PATCH] expand, ranger: Use ranger during expansion [PR120434]

On Sun, Jun 08, 2025 at 10:49:44AM +0200, Richard Biener wrote: > I'm also a bit nervous about this given during RTL expansion the IL is > neither fully GIMPLE nor fully RTL. Given we do not perform many > range queries we might be just lucky to not run into any issues? So, I've added following i

[PATCH] c++: Save 8 further bytes from lang_type allocations

Hi! The following patch implements the /* FIXME reuse another field? */ comment on the lambda_expr member. I think (and asserts in the patch seem to confirm) CLASSTYPE_KEY_METHOD is only ever non-NULL for TYE_POLYMORPHIC_P and on the other side CLASSTYPE_LAMBDA_EXPR is only used on closure types

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

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_replaceable) and there are just 2 bits left. The following patch is an attempt to s

[PATCH] c++, v2: Don't incorrectly reject override after class head name [PR120569]

On Mon, Jun 09, 2025 at 12:17:12PM -0400, Jason Merrill wrote: > > While the > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#c03-compatibility-changes-for-annex-c-diff.cpp03.dcl.dcl > > hunk dropped because > > struct C {}; struct C {} final {}; > > is actually not valid

Re: [PATCH] RISC-V: xtheadmemidx: Split slli.uw pattern [combine question]

On Mon, Jun 09, 2025 at 08:26:10AM -0600, Jeff Law wrote: > On 4/1/25 9:35 PM, Jeff Law wrote: > So returning to this > > So the combine pass doesn't reject combination into an ASM_INPUT, just > combination from most ASM_INPUTs. Yeah, exactly. > It does rely on predicates to determine valid

Re: [PATCH v3] c++: Fix template class lookup [PR120495, PR115605].

On 6/3/25 12:29 PM, Iain Sandoe wrote: Hi Jason, a bootstrap + testsuite (but without Ada or D). Hmm, it looks like make_typename_type wants to call lookup_template_class with a class as CONTEXT. But it first does the lookup separately. So I read that to indicate this does not need addr

Re: [PATCH] c++: Don't incorrectly reject override after class head name [PR120569]

On 6/6/25 12:35 PM, Jakub Jelinek wrote: Hi! While the https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#c03-compatibility-changes-for-annex-c-diff.cpp03.dcl.dcl hunk dropped because struct C {}; struct C {} final {}; is actually not valid C++98 (which didn't have list initi

Re: [PATCH] RISC-V: xtheadmemidx: Split slli.uw pattern [combine question]

Hi! On Tue, Apr 01, 2025 at 09:35:53PM -0600, Jeff Law wrote: > Segher -- there's a combine question near the end... > So this is a nasty little problem and touches on a deeper issue. > > The core problem is that combine doesn't know anything about > constraints. It works with predicates and c

Re: [PATCH 03/14] aarch64: Relaxed SEL combiner patterns for unpacked SVE FP conversions

On Mon, Jun 09, 2025 at 02:48:58PM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > On Thu, Jun 05, 2025 at 09:24:27PM +0100, Richard Sandiford wrote: > >> Spencer Abson writes: > >> > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c > >> > b/gcc/testsuite/gcc.

Re: [PATCH v2 1/2] emit-rtl: Allow extra checks for paradoxical subregs [PR119966]

On Sun, Jun 08, 2025 at 07:26:44AM +0100, Stafford Horne wrote: > On Sat, Jun 07, 2025 at 06:53:28PM +0300, Dimitar Dimitrov wrote: > > On Sat, Jun 07, 2025 at 11:38:46AM +0100, Stafford Horne wrote: > > > On Fri, Jun 06, 2025 at 09:54:53PM +0100, Stafford Horne wrote: > > > > On Fri, Jun 06, 2025

Re: [PATCH v2 1/2] emit-rtl: Allow extra checks for paradoxical subregs [PR119966]

Stafford Horne writes: > On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote: >> On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote: >> > Stafford Horne writes: >> > > Hello, >> > > >> > > This seems to be causing a build regression on the or1k port. >> > > >> > > I have

Re: [PATCH v2 1/2] emit-rtl: Allow extra checks for paradoxical subregs [PR119966]

On Sun, Jun 08, 2025 at 09:05:07AM -0600, Jeff Law wrote: > > > On 6/7/25 4:38 AM, Stafford Horne wrote: > > > > > ## Note on cstoresi4 and PUT_MODE. > > > > There was some concern raised by Jeff about the use of PUT_MODE in > > cstoresi4. > > This is here to convert a 'ne' to 'ne:SI', for ex

[PATCH] libstdc++: Implement LWG3528 make_from_tuple can perform (the equivalent of) a C-style cast

From: Yihan Wang Implement LWG3528 to make std::make_from_tuple SFINAE friendly. libstdc++-v3/ChangeLog: * include/std/tuple (__can_make_from_tuple): New variable template. (__make_from_tuple_impl): Add static_assert. (make_from_tuple): Constrain using __can_make

Re: [PATCH, FYI?] [arm] [vxworks] require thumb2 for pr120424.C

On 08/06/2025 14:15, Alexandre Oliva wrote: > > VxWorks kernel mode doesn't support thumb code, so the test fails. > Require thumb2 support. You already have -march=armv7, so that implies any thumb code will be thumb2. So this doesn't really make sense as this is a compile-only test. Furthermo

Re: [PATCH] RISC-V: xtheadmemidx: Split slli.uw pattern [combine question]

On 4/1/25 9:35 PM, Jeff Law wrote: Segher -- there's a combine question near the end... On 3/23/25 8:43 PM, Bohan Lei wrote: The combine pass can generate an index like (and:DI (mult:DI (reg:DI) (const_int scale)) (const_int mask)) when XTheadMemIdx is available. LRA may pull it out, and t

Re: [AutoFDO] Profile merging for clone test

OK, thanks! Honza

Re: message format ok?

On Sun, 8 Jun 2025 10:35:46 +0200 Richard Biener wrote: > > gcc/cobol/ChangeLog: > > > > PR cobol/120328 > > * Make-lang.in: Success with non-English locale. > > PR cobol/119695 > > This second PR reference should go right after the first (or push two > different commits)

Re: [PATCH v2] Evaluate the object size by the size of the pointee type when the type is a structure with flexible array member which is annotated with counted_by.

Ping * 2. Thanks! Qing > On May 7, 2025, at 12:59, Qing Zhao wrote: > > Hi, > > This is the 2nd version of the patch for: > > Evaluate the object size by the size of the pointee type when the type > is a structure with flexible array member which is annotated with > counted_by. > > Per th

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

Ping * 2. FYI: this feature has been committed into CLANG on 5/13/2025: https://github.com/llvm/llvm-project/pull/137250 Thanks a lot for your review. Qing > On May 13, 2025, at 17:03, Qing Zhao wrote: > > For example: > struct PP { > size_t count2; > char other1; > char *array2 __attribu

Re: [PATCH 04/14] aarch64: Add support for unpacked SVE FP comparisons

Spencer Abson writes: > On Fri, Jun 06, 2025 at 10:02:19AM +0100, Richard Sandiford wrote: >> Spencer Abson writes: >> > @@ -27292,10 +27291,16 @@ aarch64_emit_sve_invert_fp_cond (rtx target, >> > rtx_code code, rtx pred, >> > void >> > aarch64_expand_sve_vec_cmp_float (rtx target, rtx_code co

Re: [PATCH 08/14] aarch64: Add support for unpacked SVE FP binary arithmetic

Spencer Abson writes: > On Fri, Jun 06, 2025 at 12:18:15PM +0100, Richard Sandiford wrote: >> Spencer Abson writes: >> > This patch extends the expanders for unpredicated smax, smin, add, sub, >> > mul, min, and max, so that they support partial SVE FP modes. >> > >> > The relevant insn/split pat

Re: [PATCH 03/14] aarch64: Relaxed SEL combiner patterns for unpacked SVE FP conversions

Spencer Abson writes: > On Thu, Jun 05, 2025 at 09:24:27PM +0100, Richard Sandiford wrote: >> Spencer Abson writes: >> > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c >> > b/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c >> > new file mode 100644 >> > inde

[pushed: r16-1344] diagnostics: fix of experimental-html output [PR116792]

Add a new vfunc diagnostic_output_format::set_main_input_filename so that we can separate setting the of HTML output and the diagnostic_artifact_role::analysis_target of SARIF output from creation of the sinks. Calling it is done by the various creators of the sinks. Successfully bootstrapped &

Re: [PATCH 2/3]AArch64: Support eliding ptest on masked compares [PR118974]

Richard Sandiford writes: > Tamar Christina writes: >> In the example >> >> void f1 () >> { >> for (int i = 0; i < N; i++) >> { >> b[i] += a[i]; >> if (a[i] > 0) >> break; >> } >> } >> >> when compiled for SVE we generate: >> >> ld1wz28.s, p7/z, [x4, x0, lsl

Re: [PATCH v1 1/4] RISC-V: Combine vec_duplicate + vremu.vv to vremu.vx on GR2VR cost

On 6/9/25 7:11 AM, pan2...@intel.com wrote: From: Pan Li This patch would like to combine the vec_duplicate + vremu.vv to the vremu.vx. From example as below code. The related pattern will depend on the cost of vec_duplicate from GR2VR. Then the late-combine will take action if the cost o

RE: [PATCH 2/3]AArch64: Support eliding ptest on masked compares [PR118974]

> -Original Message- > From: Richard Sandiford > Sent: Monday, June 9, 2025 2:13 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > ; ktkac...@gcc.gnu.org > Subject: Re: [PATCH 2/3]AArch64: Support eliding ptest on masked compares > [PR118974] > > Richard San

[PATCH v1 3/4] RISC-V: Add test for vec_duplicate + vremu.vv combine case 0 with GR2VR cost 0, 2 and 15

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

[PATCH v1 2/4] RISC-V: Reconcile the existing test for vremu.vx combine

From: Pan Li Some existing vrem related test need some adjust for the asm check due to cost model. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/binop/vrem-rv32gcv.c: Adjust the asm check for vremu. * gcc.target/riscv/rvv/autovec/binop/vrem-rv64gcv.c: Ditto. S

[PATCH v1 1/4] RISC-V: Combine vec_duplicate + vremu.vv to vremu.vx on GR2VR cost

From: Pan Li This patch would like to combine the vec_duplicate + vremu.vv to the vremu.vx. From example as below code. The related pattern will depend on the cost of vec_duplicate from GR2VR. Then the late-combine will take action if the cost of GR2VR is zero, and reject the combination if th

[PATCH v1 4/4] RISC-V: Add test for vec_duplicate + vremu.vv combine case 1 with GR2VR cost 0, 1 and 2

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

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

From: Pan Li This patch would like to introduce the combine of vec_dup + vremu.vv into vremu.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-1247 Regression] FAIL: g++.dg/modules/xtreme-header-8.C -std=c++26 (test for excess errors) on Linux/x86_64

On Linux/x86_64, bdae7824cd9a9d27665bf1b82f60a761a9745a6a is the first bad commit commit bdae7824cd9a9d27665bf1b82f60a761a9745a6a Author: Jonathan Wakely Date: Wed Jun 4 15:53:20 2025 +0100 libstdc++: Optimize std::counting_semaphore for futex path caused FAIL: g++.dg/modules/xtreme-head

[r16-1067 Regression] FAIL: gcc.dg/tree-ssa/cswtch-6.c scan-assembler .rodata.cst16 on Linux/x86_64

On Linux/x86_64, aa935ce40a777eb0b4a4d3d2e03cf2efb4cf9619 is the first bad commit commit aa935ce40a777eb0b4a4d3d2e03cf2efb4cf9619 Author: Andrew Pinski Date: Mon Jun 2 15:56:20 2025 -0700 switch-conversion: Mark CSWTCH as mergeable [PR120451] caused FAIL: gcc.dg/tree-ssa/cswtch-6.c scan-

Re: [PATCH 02/14] aarch64: Add support for unpacked SVE FP conversions

Spencer Abson writes: > On Thu, Jun 05, 2025 at 06:11:44PM +0100, Richard Sandiford wrote: >> > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cvtf_3.c >> > b/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cvtf_3.c >> > new file mode 100644 >> > index 000..964264c4114 >> > ---

Re: [PATCH 2/3]AArch64: Support eliding ptest on masked compares [PR118974]

Tamar Christina writes: > In the example > > void f1 () > { > for (int i = 0; i < N; i++) > { > b[i] += a[i]; > if (a[i] > 0) > break; > } > } > > when compiled for SVE we generate: > > ld1wz28.s, p7/z, [x4, x0, lsl 2] > cmpgt p14.s, p7/z, z28.s, #

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

Kugan Vivekanandarajah writes: > [sending again as the email seems to have not delivered] > > Hi Richard, > >> On 7 Jun 2025, at 1:12 am, Richard Sandiford >> wrote: >> >> External email: Use caution opening links or attachments >> >> >> Jan Hubicka writes: Should I go with:

Re: [PATCH 1/4] libstdc++: Format empty chrono-spec for the calendar types directly.

On Fri, Jun 6, 2025 at 1:02 PM Tomasz Kamiński wrote: > This patch change implementation of the formatters for the calendar types, > so they no longer delegate to operator<< for ostream in case of empty > chrono-spec. > Instead of that, we define the behavior of the in terms of format > specifier

Re: [PATCH v2] libstdc++: hashing support for chrono value classes (P2592R2)

On Fri, Jun 6, 2025 at 9:07 AM Giuseppe D'Angelo wrote: > Hi Tomasz, > > Thank you for reviewing the original patch! > > I'm attaching a second version, hopefully addressing what you've > highlighed. I've also pushed it on Forge: > > https://forge.sourceware.org/gcc/gcc-TEST/pulls/52 Posted revi

RE: [PATCH 1/3]middle-end: support vec_cbranch_any and vec_cbranch_all [PR118974]

> -Original Message- > From: Richard Biener > Sent: Monday, June 9, 2025 10:30 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ; > nd > Subject: Re: [PATCH 1/3]middle-end: support vec_cbranch_any and > vec_cbranch_all [PR118974] > > On Mon, 9 Jun 2025, Tamar Ch

Re: [PATCH] forwprop: Change optimize_agr_copyprop into forward walk instead of backwards

On Sun, Jun 8, 2025 at 7:52 PM Andrew Pinski wrote: > > While thinking about how to implement the rest of the copy prop and makes > sure not > to introduce some compile time problems, optimize_agr_copyprop should be > changed > into a forwproping rather than looking backwards. Can you explain t

Re: [PATCH 11/14] aarch64: Add support for unpacked SVE FP conditional binary arithmetic

On Fri, Jun 06, 2025 at 03:52:12PM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > @@ -8165,20 +8169,25 @@ > > ;; > > ;; For unpacked vectors, it doesn't really matter whether SEL uses the > > ;; the container size or the element size. If SEL used the container size, > > -;; it wou

Re: [PATCH 13/14] aarch64: Relaxed SEL combiner patterns for unpacked SVE FP ternary arithmetic

On Fri, Jun 06, 2025 at 04:04:18PM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > Extend the ternary op/UNSPEC_SEL combiner patterns from SVE_FULL_F/ > > SVE_FULL_F_BF to SVE_F/SVE_F_BF, where the strictness value is > > SVE_RELAXED_GP. > > > > We can only reliably test the 'merging w

Re: [PATCH] [RFC] RISC-V: Add extra check to help choosing multilib with equivalent arch.

Oh, yeah, I got your point, I was just misreading, the march is rv32imac rather than rv32imafc, that is because of the complicated implication rule. So I think maybe we should mark C-ext as a EXT_FLAG_MACRO Then skip all EXT_FLAG_MACRO during riscv_subset_list::match_score? something like that:

Re: [PATCH 1/3]middle-end: support vec_cbranch_any and vec_cbranch_all [PR118974]

On Mon, 9 Jun 2025, Tamar Christina wrote: > This patch introduces two new vector cbranch optabs vec_cbranch_any and > vec_cbranch_all. > > To explain why we need two new optabs let me explain the current cbranch and > its > limitations and what I'm trying to optimize. So sorry for the long emai

Re: libstdc++: libstdc++: Implement LWG3528 make_from_tuple can perform (the equivalent of) a C-style cast

On 08/06/25 01:32 +0800, Yrong wrote: Hi libstdc++ experts, This patch implement LWG3528 and also implement an improvement that makes std::make_from_tuple SFINAE friendly. I have implemented this LWG issue and SFINAE enhancements for libc++ and Microsoft STL. This is my first patch for libstdc+

Re: [PATCH 4/4] RISC-V: Add support for xtheadvector fault-only-first segment load/store intrinsics

I got compilation issue for this patch: ../../../../riscv-gnu-toolchain-trunk/gcc/gcc/config/riscv/thead-vector-builtins-bases.cc ../../../../riscv-gnu-toolchain-trunk/gcc/gcc/config/riscv/thead-vector-builtins-bases.cc: In member function ‘rtx_def* riscv_vector::th_vlseg::exp and(riscv_v

Re: [PATCH 09/14] aarch64: Add support for unpacked SVE FDIV

On Fri, Jun 06, 2025 at 12:46:32PM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > This patch extends the unpredicated FP division expander to support > > partial FP modes. It extends the existing patterns used to implement > > UNSPEC_COND_FDIV and it's approximation as needed. > > >

回复：[PATCH] [RFC] RISC-V: Add extra check to help choosing multilib with equivalent arch.

> But rv32imaf_zca means we don't have zcf, so it can not select > rv32imac, otherwise that means the final binary will have zcf > instruction and that won't be able to run on env that only have > rv32imaf_zca. In my opinion the arch of multilib is the arch used when compiling the lib, that is the

Re: [PATCH 1/4] RISC-V: Add support for xtheadvector unit-stride segment load/store intrinsics

> diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc > index de23e410d4c..b78e2762cfa 100644 > --- a/gcc/config/riscv/thead.cc > +++ b/gcc/config/riscv/thead.cc > @@ -1059,12 +1059,17 @@ th_asm_output_opcode (FILE *asm_out_file, const char > *p) > get_attr_type (current_o

Re: [PATCH 0/4] RISC-V: Add new segment load/store intrinsics for xtheadvector

Hi Yunze: I thought the T-head vector should just reuse segments load/store pattern from standard vector instruction is enough and then adjust the output name at th_asm_output_opcode , do you have a good reason why we need to add those patterns for T-head vector again? I am really concerned about

Re: [PATCH 08/14] aarch64: Add support for unpacked SVE FP binary arithmetic

On Fri, Jun 06, 2025 at 12:18:15PM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > This patch extends the expanders for unpredicated smax, smin, add, sub, > > mul, min, and max, so that they support partial SVE FP modes. > > > > The relevant insn/split patterns have also been updated.

Re: [PATCH 04/14] aarch64: Add support for unpacked SVE FP comparisons

On Fri, Jun 06, 2025 at 10:02:19AM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > @@ -27292,10 +27291,16 @@ aarch64_emit_sve_invert_fp_cond (rtx target, > > rtx_code code, rtx pred, > > void > > aarch64_expand_sve_vec_cmp_float (rtx target, rtx_code code, rtx op0, rtx > > op1) > >

Re: [PATCH 03/14] aarch64: Relaxed SEL combiner patterns for unpacked SVE FP conversions

On Thu, Jun 05, 2025 at 09:24:27PM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > diff --git a/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c > > b/gcc/testsuite/gcc.target/aarch64/sve/unpacked_cond_cvtf_1.c > > new file mode 100644 > > index 000..8f69232f2cf > >

Re: [PATCH 02/14] aarch64: Add support for unpacked SVE FP conversions

On Thu, Jun 05, 2025 at 06:11:44PM +0100, Richard Sandiford wrote: > Spencer Abson writes: > > @@ -9487,21 +9489,39 @@ > > ;; - FCVTZU > > ;; > > - > > > > -;; Unpredicated conversion of floats to integers of the same siz

RE: AArch64 promote aarch64-autovec-peference to mautovec-preference

> >> +param value will be used. > >> + > >> @opindex march > >> @item -march=@var{name} > >> Specify the name of the target architecture and, optionally, one or > > > > --params are supposed to be internal developer flags that could go away > > at any time. So now that we have the user-facing flag

Re: [PATCH] [RFC] RISC-V: Add extra check to help choosing multilib with equivalent arch.

On Wed, May 28, 2025 at 8:03 PM yunzezhu wrote: > > > I thought this issue should be fixed when we implement those > > implication rules correctly? Does march=rv32imaf_zca/mabi=ilp32 still > > not able select march=rv32imac/mabi=ilp32 still happen after this[1] > > patch? > > > > [1] > > https://

Re: [PATCH] i386: Handle ZERO_EXTEND like SIGN_EXTEND in bsr patterns [PR120434]

On Fri, Jun 6, 2025 at 3:43 PM Jakub Jelinek wrote: > > Hi! > > The just posted second PR120434 patch causes > +FAIL: gcc.target/i386/pr78103-3.c scan-assembler m(leaq|addq|incq)M > +FAIL: gcc.target/i386/pr78103-3.c scan-assembler-not mmovlM+ > +FAIL: gcc.target/i386/pr78103-3.c s

[COMMITTED 40/40] ada: Support fixed-lower-bound array types as generic actual parameters

From: Gary Dismukes Attempting to use a fixed-lower-bound array type (or subtype) as an actual parameter for a formal unconstrained array type was being rejected by the compiler (complaining about the index type of the actual not matching the index type of the formal type). The compiler was impr

[COMMITTED 39/40] ada: Reject component-related aspects on formal non-array types

From: Piotr Trojanek In Ada 2022 aspects Atomic_Components and Volatile_Components can be specified for a formal array type, but they were wrongly accepted on any formal type. Also, we don't need to check if the corresponding pragmas appear in Ada 2022 mode, because generic formal parameters can

  1   2   >