[PATCH] RISC-V: Minimal support for zama16b extension.

2025-04-18 Thread Dongyan Chen
This patch support zama16b extension[1]. To enable GCC to recognize and process zama16b extension correctly at compile time. [1] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc gcc/ChangeLog: * common/config/riscv/riscv-common.cc: New extension. * config

[PATCH v4 1/4] libstdc++: Setup internal FTM for mdspan.

2025-04-18 Thread Luc Grosheintz
Uses the FTM infrastructure to create an internal feature testing macro for partial availability of mdspan; which is then used to hide the contents of the header mdspan when compiling against a standard prior to C++23. libstdc++-v3/ChangeLog: * include/bits/version.def: Add internal featu

[PATCH v4 2/4] libstdc++: Add header mdspan to the build-system.

2025-04-18 Thread Luc Grosheintz
Creates a nearly empty header mdspan and adds it to the build-system and Doxygen config file. libstdc++-v3/ChangeLog: * doc/doxygen/user.cfg.in: Add . * include/Makefile.am: Ditto. * include/Makefile.in: Ditto. * include/precompiled/stdc++.h: Ditto. * inclu

[PATCH v4 0/4] Implement extents from the mdspan header.

2025-04-18 Thread Luc Grosheintz
This is the fourth interation and replaces: https://gcc.gnu.org/pipermail/libstdc++/2025-April/061046.html Changes since v3: * Use `_S_` prefix for static member functions. * Use consteval to reduce code size. * Simplify ctors of _ExtentsStorage. * Added a test to cover the mandates of std

[PATCH v4 4/4] libstdc++: Add tests for std::extents.

2025-04-18 Thread Luc Grosheintz
A prior commit added std::extents, this commit adds the tests. The bulk is focussed on testing the constructors. These are split into three groups: 1. the ctor from other extents and the copy ctor, 2. the ctor from a pack of integer-like objects, 3. the ctor from shapes, i.e. span and array. For

[PATCH v4 3/4] libstdc++: Implement std::extents [PR107761].

2025-04-18 Thread Luc Grosheintz
This implements std::extents from according to N4950 and contains partial progress towards PR107761. If an extent changes its type, there's a precondition in the standard, that the value is representable in the target integer type. This precondition is not checked at runtime. The precondition fo

Re: [PATCH] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

2025-04-18 Thread Jeff Law
On 4/18/25 2:43 AM, Philipp Tomsich wrote: Applied to trunk (16.0.0), thank you! Should this be backported to the GCC-15 release branch as well? We don't have this on by default on the branch and it's a new option, so one could make the argument it's not a regression and inappropriate. But o

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

2025-04-18 Thread Jakub Jelinek
On Fri, Apr 18, 2025 at 01:53:25PM +0200, Rainer Orth wrote: > Unless this can be figured out quickly, I suspect the safest solution > for now would be to replace the (not filename-related) NAME_MAX by it's > Linux definition of 255. Something like this would be > required to unbreak Solaris/amd6

Re: [PATCH v4 3/4] libstdc++: Implement std::extents [PR107761].

2025-04-18 Thread Tomasz Kaminski
On Fri, Apr 18, 2025 at 2:00 PM Tomasz Kaminski wrote: > > > > On Fri, Apr 18, 2025 at 1:43 PM Luc Grosheintz > wrote: > >> This implements std::extents from according to N4950 and >> contains partial progress towards PR107761. >> >> If an extent changes its type, there's a precondition in the

Re: [PATCH] Fix wrong optimization of conditional expression with enumeration type

2025-04-18 Thread Eric Botcazou
> I'd reword this to > > "Similarly, TYPE_UNSIGNED is false for components of vector masks and > possibly for boolean types in languages other than C." > > That is, the C/middle-end boolean_type_node is always unsigned. OK, thanks, I have installed the attached patch. -- Eric Botcazoudiff --gi

Re: [PATCH v3 3/4] libstdc++: Implement std::extents [PR107761].

2025-04-18 Thread Tomasz Kaminski
On Thu, Apr 17, 2025 at 6:07 PM Luc Grosheintz wrote: > > On 4/17/25 2:31 PM, Tomasz Kaminski wrote: > > > > On Thu, Apr 17, 2025 at 2:21 PM Tomasz Kaminski > wrote: > >> >> >> On Thu, Apr 17, 2025 at 1:44 PM Tomasz Kaminski >> wrote: >> >>> >>> >>> On Thu, Apr 17, 2025 at 1:18 PM Luc Grosheint

Re: [PATCH] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

2025-04-18 Thread Philipp Tomsich
Applied to trunk (16.0.0), thank you! Should this be backported to the GCC-15 release branch as well? --Philipp. On Mon, 31 Mar 2025 at 10:10, Philipp Tomsich wrote: > > Jeff, > > > On Sun, 30 Mar 2025 at 01:48, Jeff Law wrote: > > > > > > > > On 3/28/25 5:12 AM, Konstantinos Eleftheriou wrote:

[PATCH v2] libstdc++-v3: Implement missing allocator-aware constructors for unordered containers.

2025-04-18 Thread Tomasz Kamiński
This patch implements remainder of LWG2713 (after r15-8293-g64f5c854597759) by adding missing allocator aware version of unordered associative containers constructors accepting pair of iterators or initializer_list, and corresponding deduction guides. libstdc++-v3/ChangeLog: * include/bit

Re: [PATCH] libgcobol: Check for struct tm tm_zone

2025-04-18 Thread Rainer Orth
Rainer Orth writes: > Hi Andreas, > >> On Apr 11 2025, Rainer Orth wrote: >> >>> This patch uses Autoconf's AC_STRUCT_TIMEZONE to determine its presence >>> and guard the use accordingly. >> >> You cannot use AC_STRUCT_TIMEZONE because it requires a link test (which >> is forbidden in a target mo

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

2025-04-18 Thread Rainer Orth
Richard Biener writes: > On Fri, Apr 11, 2025 at 2:14 PM Rainer Orth > wrote: >> >> Andreas Schwab writes: >> >> > On Apr 11 2025, Rainer Orth wrote: >> > >> >> All users of symbols.h fail to compile on Solaris: >> >> >> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope: >>

Re: [PATCH] cobol: Don't require GLOB_BRACE etc. [PR119217]

2025-04-18 Thread Rainer Orth
ping? It's been a week and this is required to unbreak Solaris/amd64 bootstrap with --enable-languages=all: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680675.html Thus it should go into both trunk and the gcc-15 branch. Thanks. Rainer Rainer Orth writes: > cdf-copy.cc does

Re: [PATCH] cobol: Initialize regmatch_t portably [PR119217]

2025-04-18 Thread Rainer Orth
Rainer Orth writes: > Hi Jakub, > >> On Fri, Apr 11, 2025 at 10:50:25AM +0200, Rainer Orth wrote: >>> 2025-04-08 Rainer Orth >>> >>> gcc/cobol: >>> PR cobol/119217 >>> * dts.h (csub_match): Initialize rm_so, rm_eo fields explicitly. >>> >> >>> # HG changeset patch >>> # Parent 6

[PATCH] libstdc++: Strip reference and cv-qual in range deduction guides for maps.

2025-04-18 Thread Tomasz Kamiński
This implements part of LWG4223 that adjust the deduction guides for maps types (map, unordered_map, flat_map and non-unique equivalent) from "range", such that referience and cv qualification are stripped from the element of the pair-like value_type. In combination with r15-8296-gd50171bc07006d,

Re: [PATCH v4 3/4] libstdc++: Implement std::extents [PR107761].

2025-04-18 Thread Tomasz Kaminski
On Fri, Apr 18, 2025 at 1:43 PM Luc Grosheintz wrote: > This implements std::extents from according to N4950 and > contains partial progress towards PR107761. > > If an extent changes its type, there's a precondition in the standard, > that the value is representable in the target integer type.

[PATCH] libstdc++: Clarify that _S_ prefix is be used for static member functions.

2025-04-18 Thread Tomasz Kamiński
libstdc++-v3/ChangeLog: * doc/xml/manual/appendix_contributing.xml: Add 'and functions'. --- OK for trunk? libstdc++-v3/doc/xml/manual/appendix_contributing.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml b/li

[PATCH] x86: Add preserve_none and update no_caller_saved_registers attributes

2025-04-18 Thread H.J. Lu
Add preserve_none attribute which is similar to no_callee_saved_registers attribute, except on x86-64, r12, r13, r14, r15, rdi and rsi registers are used for integer parameter passing. This can be used in an interpreter to avoid saving/restoring the registers in functions which processing byte cod

Fix time zone for 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob' [PR119818] (was: cobol: [committed] More testcases)

2025-04-18 Thread Thomas Schwinge
Hi! On 2025-04-04T15:17:53-0500, Robert Dubner wrote: > * cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob: Likewise. OK to push to trunk branch (and releases/gcc-15 branch, eventually) "Fix time zone for 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob' [PR119818]", see attached?

[PATCH] tree-optimization/119858 - type mismatch with POINTER_PLUS

2025-04-18 Thread Richard Biener
The recent PFA early-break vectorization fix left us with a POINTER_PLUS and non-sizetype offset. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. I'll push to trunk and branch. PR tree-optimization/119858 * tree-vect-loop.cc (vectorizable_live_operation): Convert

Re: [PATCH 2/2] DSE: Trim stores of 0 like triming stores of {} [PR87901]

2025-04-18 Thread Jeff Law
On 4/17/25 9:12 PM, Andrew Pinski wrote: This is the second part of the PR which comes from transformation of memset into either stores of 0 (via an integral type) or stores of {}. We already handle stores of `{}`, this just extends that to handle of the constant 0 and treat it similarly.

[RISC-V] Fix missed bext discovery

2025-04-18 Thread Jeff Law
RISC-V has the ability to extract a single bit out of a register from a fixed or variable position. While looking at 502.gcc a little while ago I realize that we failed to use bext inside bitmap_bit_p for its return value. The core "problem" is that the RISC-V does not define SHIFT_COUNT_T

Re: [PATCH] [riscv] vec_dup immediate constants in pred_broadcast expand [PR118182]

2025-04-18 Thread Jeff Law
On 4/12/25 12:41 AM, Alexandre Oliva wrote: pr118182-2.c fails on gcc-14 because it lacks the late_combine passes, particularly the one that runs after register allocation. Even in the trunk, the predicate broadcast for the add reduction is expanded and register-allocated as _zvfh, taking up

RE: [PATCH 1/3][GCC16-Stage-1] RISC-V: Combine vec_duplicate + vadd.vv to vadd.vx on GR2VR cost

2025-04-18 Thread Li, Pan2
Thanks Jeff for comments. > So we've got 3 patches all touching on the same basic area, so we need > to be careful about staging in. Agree, thanks Jeff for paying attention. > So don't be surprised if most review time is focused on how the costing > model works since that's a common theme acro

Re: [PATCH] c6x: Fix EHTYPE relocations

2025-04-18 Thread Jeff Law
On 4/14/25 4:26 AM, Richard Braun wrote: R_C6000_EHTYPE relocations are implemented as GOT-indirect relocations, but, as specified by the C6000 EABI (SPRAB89A), 13.5.1 Relocation Types, they are a special case of SBR (static base relocation). gcc/ * config/c6x/c6x.h (ASM_PREFERRED_EH_

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

2025-04-18 Thread Jerry D
On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef" in it. I.e. something that really ma

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

2025-04-18 Thread Jerry D
On 4/18/25 8:05 AM, Jerry D wrote: On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef

Re: [PATCH 1/3][GCC16-Stage-1] RISC-V: Combine vec_duplicate + vadd.vv to vadd.vx on GR2VR cost

2025-04-18 Thread Jeff Law
On 4/17/25 1:30 AM, pan2...@intel.com wrote: From: Pan Li This patch would like to combine the vec_duplicate + vadd.vv to the vadd.vx. From example as below code. The related pattern will depend on the cost of vec_duplicate from GR2VR, it will: * The pattern matching will be inactive if G

[PATCH] RISC-V: Minimal support for sdtrig and ssstrict extensions.

2025-04-18 Thread Dongyan Chen
This patch support sdtrig and ssstrict extensions[1]. To enable GCC to recognize and process sdtrig and ssstrict extensions correctly at compile time. [1] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc gcc/ChangeLog: * common/config/riscv/riscv-common.cc: New e

Re: [PATCH] gimple: Canonical order for invariants [PR118902]

2025-04-18 Thread Jeff Law
On 4/17/25 11:35 AM, Andrew Pinski wrote: So unlike constants, address invariants are currently put first if used with a SSA NAME. It would be better if address invariants are consistent with constants and this patch changes that. gcc.dg/tree-ssa/pr118902-1.c is an example where this canonical

Re: [PATCH] gimple-fold: Improve optimize_memcpy_to_memset by walking back until aliasing says the ref is a may clobber. [PR118947]

2025-04-18 Thread Jeff Law
On 4/17/25 11:50 AM, Andrew Pinski wrote: The case here is we have: ``` char buf[32] = {}; void* ret = aaa(); __builtin_memcpy(ret, buf, 32); ``` And buf does not escape. But we don't prop the zeroing from buf to the memcpy statement because optimize_memcpy_to_memset only loo

Re: [PATCH V2] RISC-V: Add support for Zalasr extension

2025-04-18 Thread Jeff Law
On 4/10/25 3:48 PM, Edwin Lu wrote: [1] https://github.com/riscv/riscv-zalasr Add minimal support for the zalasr (load-acquire/store-release) extension Currently there is no toggle to opt into the abi-breaking note 3 mappings in the PSABI doc so support for that has been omitted from this pa

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

2025-04-18 Thread Rainer Orth
Hi Jakub, > On Fri, Apr 18, 2025 at 01:53:25PM +0200, Rainer Orth wrote: >> Unless this can be figured out quickly, I suspect the safest solution >> for now would be to replace the (not filename-related) NAME_MAX by it's >> Linux definition of 255. Something like this would be >> required to unb

Re: [PATCH v15] ada: fix timeval timespec on 32 bits archs with 64 bits time_t [PR114065]

2025-04-18 Thread Marc Poulhiès
On Sun Apr 13, 2025 at 9:18 PM CEST, Nicolas Boulenguez wrote: > Hello. Hello! > Please skip v14 and review v15. A diff with v13 is attached. > The full v15 is at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065, but my SMTP > server refused them as attachments. Ok! (from previous mail) >

Re: [PING][PATCH] doc: Clarify REG_EH_REGION note usage

2025-04-18 Thread Philipp Tomsich
Applied to trunk, thank you! --Philipp. On Thu, 17 Apr 2025 at 21:51, Jeff Law wrote: > > > > On 4/8/25 6:12 AM, Konstantinos Eleftheriou wrote: > > Hi, > > Just a ping for https://gcc.gnu.org/pipermail/gcc-patches/2025- > > March/677635.html >

Re: [PATCH v3 3/4] libstdc++: Implement std::extents [PR107761].

2025-04-18 Thread Tomasz Kaminski
On Thu, Apr 17, 2025 at 3:00 PM Luc Grosheintz wrote: > Thank you for another excellent review! > On 4/17/25 1:44 PM, Tomasz Kaminski wrote: > > > > On Thu, Apr 17, 2025 at 1:18 PM Luc Grosheintz > wrote: > >> This implements std::extents from according to N4950 and >> contains partial progress

[PATCH] libstdc++: Use scope guard for deallocating nodes in deque.

2025-04-18 Thread Tomasz Kamiński
This patch adds a _Guard_nodes scope guard nested to the _Deque_base, that deallocates the range of nodes, and replaces __try/__catch block with approparietly constructed guard object. libstdc++-v3/ChangeLog: * include/bits/deque.tcc (_Deque_base<_Tp, _Alloc>::_Guard_nodes): Define.

Re: [pushed][PATCH] LoongArch: Change {dg-do-what-default} save and restore logical

2025-04-18 Thread Lulu Cheng
The changelog format has been modified and pushed to r16-13 and r15-9556. 在 2025/4/16 上午10:29, Xing Li 写道: The set of {dg-do-what-default} to 'run' may lead some test hang during make check. gcc/testsuite *gcc.target/loongarch/vector/loongarch-vector.exp: Change {d

Re: [PATCH] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

2025-04-18 Thread Sam James
Philipp Tomsich writes: > Applied to trunk (16.0.0), thank you! > Should this be backported to the GCC-15 release branch as well? BTW, what's the plan for enabling this on trunk now by default? (I don't recall if some other issues were left.)

[patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

2025-04-18 Thread Jerry D
I will be committing a fix for this to the 16 mainline tonight. I am requesting Release Manager approval to push to 15 release branch after full testing here. Regards, Jerry See attached diff. 2025-04-18 Steven G. Kargl PR fortran/119836 * resolve.cc(check_pure_function, pure_subroutine

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

2025-04-18 Thread Jakub Jelinek
On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: > That's one option, but maybe it's better the other way round: instead of > excluding known-bad targets, restrict cobol to known-good ones > (i.e. x86_64-*-linux* and aarch64-*-linux*) instead. > > I've been using the following for this

Re: [PATCH v4 0/4] Implement extents from the mdspan header.

2025-04-18 Thread Luc Grosheintz
I have a question about how to proceed. First we finish the refinement of the current commits. Then I could: 1. start a new patch series for layout_*; 2. or add new commits to the current series for layout_*. The advantage of 2. is that we can do more tests before merging anything into trunk. Fo

Re: [PATCH v4 0/4] Implement extents from the mdspan header.

2025-04-18 Thread Tomasz Kaminski
On Fri, Apr 18, 2025 at 1:56 PM Luc Grosheintz wrote: > I have a question about how to proceed. First we finish the > refinement of the current commits. Then I could: > > 1. start a new patch series for layout_*; > 2. or add new commits to the current series for layout_*. > My personal preference

Re: [PATCH v4 4/4] libstdc++: Add tests for std::extents.

2025-04-18 Thread Tomasz Kaminski
On Fri, Apr 18, 2025 at 1:37 PM Luc Grosheintz wrote: > A prior commit added std::extents, this commit adds the tests. The bulk > is focussed on testing the constructors. These are split into three > groups: > > 1. the ctor from other extents and the copy ctor, > 2. the ctor from a pack of intege

Re: [PATCH v4 0/4] Implement extents from the mdspan header.

2025-04-18 Thread Tomasz Kaminski
The whole patch series now LGTM to me. Note, that you need separate approval from the maintainer (most likely from Jonathan) for merging. On Fri, Apr 18, 2025 at 1:32 PM Luc Grosheintz wrote: > This is the fourth interation and replaces: > https://gcc.gnu.org/pipermail/libstdc++/2025-April/06104

RE: [PATCH] libgcobol: Check for struct tm tm_zone

2025-04-18 Thread Robert Dubner
> -Original Message- > From: Rainer Orth > Sent: Friday, April 18, 2025 07:50 > To: Andreas Schwab > Cc: gcc-patches@gcc.gnu.org; Robert Dubner ; James K. > Lowden ; Jakub Jelinek > Subject: Re: [PATCH] libgcobol: Check for struct tm tm_zone > > Rainer Orth writes: > > > Hi Andreas, >

RE: Fix time zone for 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob' [PR119818] (was: cobol: [committed] More testcases)

2025-04-18 Thread Robert Dubner
> -Original Message- > From: Thomas Schwinge > Sent: Friday, April 18, 2025 07:11 > To: Robert Dubner ; gcc-patches@gcc.gnu.org > Cc: sch...@linux-m68k.org > Subject: Fix time zone for > 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob' [PR119818] (was: cobol: > [committed] More testcases

Re: [PATCH] [RISC-V] Tune for removal unnecessary sext in builtin overflows [PR108016]

2025-04-18 Thread Jeff Law
On 2/14/25 9:38 AM, Alexey Merzlyakov wrote: It fixes one of the PR108016 mis-optimization. The patch adjusts expanding for __builtin_add/sub_overflow() on RV64 targets to avoid unnecessary sext.w instructions. It replaces expanded for ADD/SUB_OVERFLOW code: r141:SI=r139:DI#0+r140:DI#0 ..

Re: [PATCH v2]RISC-V:Add xuantie C908, C910, C920v1 and C920v2 to -mcpu

2025-04-18 Thread Jeff Law
On 3/20/25 3:31 AM, Yixuan Chen wrote: Hi Majin,  Thanks for your suggestion, Look like the document don't contain the following tune information: /* fmv_cost */, /* vector_unaligned_access */, /* use_divmod_expansion */, and /* overlap_op_by_pieces */ , I will follow your further modificat

Re: [PATCH] [RISC-V] Tune for removal unnecessary sext in builtin overflows [PR108016]

2025-04-18 Thread Alexey Merzlyakov
On Fri, Apr 18, 2025 at 06:47:51AM -0600, Jeff Law wrote: > Thanks. I've pushed this to the trunk. I know there's an additional patch > in this space. It'll take some time to get to as we work through the queue > of pending stuff. > > jeff Thank you for taking care of it. Yeah, there is no sen

Re: [PATCH] testsuite: Use int size instead of alignment for pr116357.c

2025-04-18 Thread Jeff Law
On 1/29/25 11:35 AM, Dimitar Dimitrov wrote: The test case assumes that alignof(int)=sizeof(int). But for some targets this is not valid. For example, for PRU target, alignof(int)=1 but sizeof(int)=4. Fix the test case to align to twice the size of int, as the expected dg-error messages sug

Re: [PATCH] libstdc++: Constrain formatters for chrono types [PR119517]

2025-04-18 Thread Tomasz Kaminski
As the formattable concept is used for the formatting of ranges and tuples that was shipped in v15, I do not think there is a real need to backport this to v14. There is not much harm in getting wrong response before range and tuple formatter are implemented. So maybe we should keep in on v15+ only

Add sse_fp_cost into i386_rtx_costs

2025-04-18 Thread Jan Hubicka
Hi, Znver5 has addss cost of 2 while other common floating point SSE operations costs 3 cycles. We currently have only one entry in the costs tables which makes it impossible to model this. This patch adds sse_fp_op which is used for other common FP operations (basically conversions) and updates

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

2025-04-18 Thread Mike Stump
On Apr 10, 2025, at 6:38 AM, Christophe Lyon wrote: > > On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote: >> >>> From: Christophe Lyon >>> Date: Thu, 10 Apr 2025 15:21:23 +0200 >> >> Not sure why I'm CC:ed on this one, not being a maintainer >> of the testsuite or targets where gcov tes

Re: [PATCH] libstdc++: Clarify that _S_ prefix is be used for static member functions.

2025-04-18 Thread Jonathan Wakely
On Fri, 18 Apr 2025, 08:41 Tomasz Kamiński, wrote: > libstdc++-v3/ChangeLog: > > * doc/xml/manual/appendix_contributing.xml: Add 'and functions'. > --- > OK for trunk? > OK, thanks. > libstdc++-v3/doc/xml/manual/appendix_contributing.xml | 2 +- > 1 file changed, 1 insertion(+), 1 del

Re: [PATCH v4 2/4] libstdc++: Add header mdspan to the build-system.

2025-04-18 Thread Tomasz Kaminski
On Fri, Apr 18, 2025 at 1:33 PM Luc Grosheintz wrote: > Creates a nearly empty header mdspan and adds it to the build-system and > Doxygen config file. > > libstdc++-v3/ChangeLog: > > * doc/doxygen/user.cfg.in: Add . > * include/Makefile.am: Ditto. > * include/Makefile.in:

Re: [PATCH] riscv: Add support for riscv*-gnu (GNU/Hurd on RISC-V)

2025-04-18 Thread Jeff Law
On 4/7/25 6:40 AM, Hakan Candar wrote: This produces a toolchain that can successfully build binaries targeting riscv*-gnu. gcc/ChangeLog: * config.gcc: Recognize riscv*-*-gnu* targets. * config/riscv/gnu.h: New file. Thanks. I've pushed this to the trunk. jeff

Re: [PATCH 1/2] DSE: Support triming of some more memset [PR87901]

2025-04-18 Thread Jeff Law
On 4/17/25 9:12 PM, Andrew Pinski wrote: DSE has support for trimming memset (and memset like) statements. In this case we have `MEM [(char * {ref-all})&z] = {};` in the IR and when we go to trim it, we call build_fold_addr_expr which leaves around PR tree-optimization/87901 gcc/Ch

Re: [PATCH] ref-temp1.C: Enable some tests for PE targets

2025-04-18 Thread Jonathan Yong
On 4/15/25 11:46 AM, Jonathan Yong wrote: Attached patch OK for master branch? Will push soon if there are no objections. Pushed to master branch.

[pushed] c++: vec_safe_reserve usage tweaks

2025-04-18 Thread Jason Merrill
Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A couple of cleanups from noticing that the semantics of std::vector::reserve() (request the new minimum allocation) differ from the GCC vec<...>::reserve() (request a minimum number of slots available). In preserve_state, we were tripling

Re: [wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update

2025-04-18 Thread Gerald Pfeifer
On Thu, 17 Apr 2025, Tobias Burnus wrote: > * https://gcc.gnu.org/projects/gomp/ This is a no-brainer. Please go ahead and push (and any such changes in the future). It does make me wonder whether we really need/want distinct docs for minor releases or shouldn't better keep just one for the br

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

2025-04-18 Thread Jerry D
On 4/18/25 5:48 PM, Jerry D wrote: I will be committing a fix for this to the 16 mainline tonight. I am requesting Release Manager approval to push to 15 release branch after full testing here. Regards, Jerry See attached diff. 2025-04-18  Steven G. Kargl  PR fortran/119836 * resolve.cc(

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

2025-04-18 Thread Jerry D
On 4/18/25 9:13 AM, Paul Richard Thomas wrote: Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild > wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request f

[r16-23 Regression] FAIL: gcc.dg/pr118947-1.c scan-tree-dump-times forwprop1 "after previous" 1 on Linux/x86_64

2025-04-18 Thread haochen.jiang
On Linux/x86_64, 7b4849ec79873fa6de98436deda47e19cbac32ef is the first bad commit commit 7b4849ec79873fa6de98436deda47e19cbac32ef Author: Andrew Pinski Date: Mon Feb 24 12:33:32 2025 -0800 gimple-fold: Improve optimize_memcpy_to_memset by walking back until aliasing says the ref is a may

[PATCH RFC] c++: bad pending_template recursion

2025-04-18 Thread Jason Merrill
limit_bad_template_recursion currently avoids immediate instantiation of templates from uses in an already ill-formed instantiation, but we still can get unnecessary recursive instantiation in pending_templates if the instantiation was queued before the error. Currently this regresses several libs

[PATCH] strlen: Don't do the malloc+memset->calloc optimization in some cases [PR83022]

2025-04-18 Thread Andrew Pinski
This fixes a long standing (since GCC 5) issue where the malloc+memset->calloc optimization would happen even if the memset was not always executed. This is a varient of Nathan's patch: https://inbox.sourceware.org/gcc-patches/f4b5d106-8176-b7bd-709b-d43518878...@acm.org/ Jeff Law had suggested to

Re: [PATCH RFC] c++: bad pending_template recursion

2025-04-18 Thread Jonathan Wakely
On Fri, 18 Apr 2025 at 23:08, Jason Merrill wrote: > > limit_bad_template_recursion currently avoids immediate instantiation of > templates from uses in an already ill-formed instantiation, but we still can > get unnecessary recursive instantiation in pending_templates if the > instantiation was q

[r16-22 Regression] FAIL: gcc.dg/pr78408-3.c scan-tree-dump-times forwprop1 "after previous" 1 on Linux/x86_64

2025-04-18 Thread haochen.jiang
On Linux/x86_64, 94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1 is the first bad commit commit 94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1 Author: Andrew Pinski Date: Thu Feb 20 16:09:05 2025 -0800 gimple-fold: Improve optimize_memcpy_to_memset to handle STRING_CST [PR78408] caused FAIL: gcc.dg/

Re: [r16-22 Regression] FAIL: gcc.dg/pr78408-3.c scan-tree-dump-times forwprop1 "after previous" 1 on Linux/x86_64

2025-04-18 Thread Andrew Pinski
On Fri, Apr 18, 2025, 7:29 PM haochen.jiang wrote: > On Linux/x86_64, > > 94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1 is the first bad commit > commit 94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1 > Author: Andrew Pinski > Date: Thu Feb 20 16:09:05 2025 -0800 > > gimple-fold: Improve optimize_memc

Re: [PATCH] except: Don't use the cached value of the gcc_except_table section for comdat functions [PR119507]

2025-04-18 Thread Andrew Pinski
On Fri, Mar 28, 2025 at 9:58 PM Andrew Pinski wrote: > > This has been broken since GCC started to put the comdat functions' > gcc_except_table into their > own section; r0-118218-g3e6011cfebedfb. What would happen is after a > non-comdat function is processed, > the cached value would always be

PING: [PATCH v2] x86: Add pcmpeq splitters

2025-04-18 Thread H.J. Lu
On Mon, Dec 2, 2024 at 6:27 AM H.J. Lu wrote: > > Add pcmpeq splitters to split > > (insn 5 3 7 2 (set (reg:V4SI 100) > (eq:V4SI (reg:V4SI 98) > (reg:V4SI 98))) 7910 {*sse2_eqv4si3} > (expr_list:REG_DEAD (reg:V4SI 98) > (expr_list:REG_EQUAL (eq:V4SI (const_vector:V

PING: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

2025-04-18 Thread H.J. Lu
On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > For all different modes of all 0s/1s vectors, we can use the single widest > all 0s/1s vector register for all 0s/1s vector uses in the whole function. > Add a pass to generate a single widest all 0s/1s vector set instruction at > entry of the near

Re: [Patch] Fortran/OpenMP: Support automatic mapping allocatable components (deep mapping)

2025-04-18 Thread Thomas Schwinge
Hi Tobias! On 2025-04-15T11:30:18+0200, Tobias Burnus wrote: > --- /dev/null > +++ b/libgomp/testsuite/libgomp.fortran/map-alloc-comp-6.f90 > @@ -0,0 +1,308 @@ > +! NOTE: This code uses POINTER. > +! While map(p, var%p) etc. maps the ptr/ptr comp p / var%p (incl. > allocatable comps), > +! map(v

Re: [PATCH]RISCV :Added MIPS P8700 Subtarget

2025-04-18 Thread Jeff Law
On 4/11/25 6:02 AM, Umesh Kalappa wrote: This is the first patch from the two-patch series, where configured gcc for P8700 micro architecture in the first patch and Tested with dejagnu riscv.exp tests for --mtune=mips-p8700. P8700 is a high-performance processor from MIPS by extending RIS

Re: [PATCH 2/2] DSE: Trim stores of 0 like triming stores of {} [PR87901]

2025-04-18 Thread Andrew Pinski
On Fri, Apr 18, 2025 at 6:21 AM Jeff Law wrote: > > > > On 4/17/25 9:12 PM, Andrew Pinski wrote: > > This is the second part of the PR which comes from transformation > > of memset into either stores of 0 (via an integral type) or stores > > of {}. We already handle stores of `{}`, this just exten

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

2025-04-18 Thread Paul Richard Thomas
Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild wrote: > Hi Jerry, > > thanks for the review and sorry for the long delay. With publishing the > team's > patches for gfortran, I also created a pull request for OpenCoarrays. > There I > was asked to add some testcase with more "beef" in

Re: [PATCH 1/2] DSE: Support triming of some more memset [PR87901]

2025-04-18 Thread Andrew Pinski
On Thu, Apr 17, 2025 at 8:30 PM Sam James wrote: > > Andrew Pinski writes: > > > DSE has support for trimming memset (and memset like) statements. > > In this case we have `MEM [(char * {ref-all})&z] = {};` > > in > > the IR and when we go to trim it, we call build_fold_addr_expr which leaves

PATCH RFC: -fdump-lang-tinst and -fdump-lang-constexpr

2025-04-18 Thread Jason Merrill
A comment on IRC yesterday made me think it shouldn't be too hard to give more insight into constexpr evaluation in the form of a dump, so here's a quick sketch. This also adds -fdump-lang-tinst for tracing template instantiations. Thoughts?Checking c01cef92b1d79175853214f9121f6d98e5cd5030: OK

[committed] d: Fix infinite loop regression in CTFE

2025-04-18 Thread Iain Buclaw
Hi, This patch merges the D front-end with upstream dmd 956e73d64e. An infinite loop was introduced by a previous refactoring in the semantic pass for DeclarationExp nodes. Ensure the loop properly terminates and add tests cases. Bootstrapped and regression tested on x86_64-linux-gnu/-m32, and c

[PATCH v3 3/4] libstdc++: Implement std::extents [PR107761].

2025-04-18 Thread Luc Grosheintz
This implements std::extents from according to N4950 and contains partial progress towards PR107761. If an extent changes its type, there's a precondition in the standard, that the value is representable in the target integer type. This precondition is not checked at runtime. The precondition fo

Re: [PATCH] libstdc++: Strip reference and cv-qual in range deduction guides for maps.

2025-04-18 Thread Jonathan Wakely
On Fri, 18 Apr 2025, 12:55 Tomasz Kamiński, wrote: > This implements part of LWG4223 that adjust the deduction guides for maps > types > (map, unordered_map, flat_map and non-unique equivalent) from "range", > such that > referience and cv qualification are stripped from the element of the > pair

Re: [PATCH] LoongArch: Change {dg-do-what-default} save and restore logical

2025-04-18 Thread Lulu Cheng
在 2025/4/16 上午10:29, Xing Li 写道: The set of {dg-do-what-default} to 'run' may lead some test hang during make check. gcc/testsuite *gcc.target/loongarch/vector/loongarch-vector.exp: Change {dg-do-what-default} save and restore logical Hi, There is a problem wit

Re: [PATCH 1/2] arc: Add commutative multiplication patterns.

2025-04-18 Thread Jeff Law
On 3/18/25 10:22 AM, Luis Silva wrote: This patch introduces two new instruction patterns: `*mulsi3_cmp0`: This pattern performs a multiplication and sets the CC_Z register based on the result, while also storing the result of the multiplication in a general-purpose regis

Re: [PATCH 2/2] arc: Use intrinsics for __builtin_mul_overflow ()

2025-04-18 Thread Jeff Law
On 3/18/25 10:23 AM, Luis Silva wrote: This patch handles both signed and unsigned builtin multiplication overflow. Uses the "mpy.f" instruction to set the condition codes based on the result. In the event of an overflow, the V flag is set, triggering a conditional move depending on the V fl

Re: [PATCH v4 3/4] libstdc++: Implement std::extents [PR107761].

2025-04-18 Thread Luc Grosheintz
On 4/18/25 2:00 PM, Tomasz Kaminski wrote: On Fri, Apr 18, 2025 at 1:43 PM Luc Grosheintz > wrote: This implements std::extents from according to N4950 and contains partial progress towards PR107761. If an extent changes its type, there's a pr

Re: [PATCH] arc: testsuite: Scan "rlc" instead of "mov.hs".

2025-04-18 Thread Jeff Law
On 3/18/25 10:23 AM, Luis Silva wrote: Due to the patch by Roger Sayle, 09881218137f4af9b7c894c2d350cf2ff8e0ee23, which introduces the use of the `rlc rX,0` instruction in place of the `mov.hs`, the add overflow test case needs to be updated. The previous test case was validating the `mov.hs`