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

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

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

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 fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

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

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

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

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

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

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.)

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

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] cobol: Allow for undefined NAME_MAX [PR119217]

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 3/4] libstdc++: Implement std::extents [PR107761].

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".

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`

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

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 1/2] arc: Add commutative multiplication patterns.

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]RISCV :Added MIPS P8700 Subtarget

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] testsuite: Use int size instead of alignment for pr116357.c

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 1/2] DSE: Support triming of some more memset [PR87901]

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

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

在 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] libstdc++: Constrain formatters for chrono types [PR119517]

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

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

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.

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

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/OpenMP: Support automatic mapping allocatable components (deep mapping)

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] libstdc++: Strip reference and cv-qual in range deduction guides for maps.

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: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

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 2/2] DSE: Trim stores of 0 like triming stores of {} [PR87901]

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: [PATCH v15] ada: fix timeval timespec on 32 bits archs with 64 bits time_t [PR114065]

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: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

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 V2] RISC-V: Add support for Zalasr extension

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] gimple: Canonical order for invariants [PR118902]

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]

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 1/3][GCC16-Stage-1] RISC-V: Combine vec_duplicate + vadd.vv to vadd.vx on GR2VR cost

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

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

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] c6x: Fix EHTYPE relocations

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: [PATCH 1/3][GCC16-Stage-1] RISC-V: Combine vec_duplicate + vadd.vv to vadd.vx on GR2VR cost

es@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com; Chen, Ken ; Liu, Hongtao ; Paul-Antoine Arras ; Alexandre Oliva Subject: Re: [PATCH 1/3][GCC16-Stage-1] RISC-V: Combine vec_duplicate + vadd.vv to vadd.vx on GR2VR cost On 4/17/25 1:30 AM, pan2...@intel.

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

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: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

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: [PATCH v4 3/4] libstdc++: Implement std::extents [PR107761].

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] cobol: Allow for undefined NAME_MAX [PR119217]

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] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

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] [RISC-V] Tune for removal unnecessary sext in builtin overflows [PR108016]

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 2/2] DSE: Trim stores of 0 like triming stores of {} [PR87901]

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.

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

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 v4 2/4] libstdc++: Add header mdspan to the build-system.

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)

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 v2]RISC-V:Add xuantie C908, C910, C920v1 and C920v2 to -mcpu

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]

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: Fix time zone for 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob' [PR119818] (was: cobol: [committed] More testcases)

> -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] libgcobol: Check for struct tm tm_zone

> -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

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

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 v4 4/4] libstdc++: Add tests for std::extents.

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.

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 0/4] Implement extents from the mdspan header.

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 3/4] libstdc++: Implement std::extents [PR107761].

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.

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

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

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

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]

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] libgcobol: Check for struct tm tm_zone

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 v3 3/4] libstdc++: Implement std::extents [PR107761].

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

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

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: [PING][PATCH] doc: Clarify REG_EH_REGION note usage

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] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

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:

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

> 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].

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: [pushed][PATCH] LoongArch: Change {dg-do-what-default} save and restore logical

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][v13] libstdc++: Correct preprocessing checks for floatX_t and bfloat_16 formatting

On Thu, 17 Apr 2025 at 14:16, Tomasz Kamiński wrote: > > Floating points types _Float16, _Float32, _Float64, and bfloat16, > can be formatted only if std::to_chars overloads for such types > were provided. Currently this is only the case for architectures > where float and double are 32-bits and 6

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

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 > around This looks cut off?

Re: [PATCH v2] x86: Update memcpy/memset inline strategies for -mtune=generic

On Tue, Apr 8, 2025 at 3:52 AM H.J. Lu wrote: > > Simplify memcpy and memset inline strategies to avoid branches for > -mtune=generic: > > 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector >load and store for up to 16 * 16 (256) bytes when the data size is >fixed and kn

RE: [PATCH] Add COBOL information to gcc.gnu.org index.html

In the absence of commentary, I have pushed those documentation changes. > -Original Message- > From: Robert Dubner > Sent: Thursday, April 17, 2025 20:26 > To: Sam James > Cc: gcc-patches@gcc.gnu.org > Subject: RE: [PATCH] Add COBOL information to gcc.gnu.org index.

RE: [PATCH] Add COBOL information to gcc.gnu.org index.html

I wonder how I missed that? Thanks. > -Original Message- > From: Sam James > Sent: Thursday, April 17, 2025 18:31 > To: Robert Dubner > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Add COBOL information to gcc.gnu.org index.html > > Robert Dubner writes

Re: [PATCH] Add _GLIBCXX_DEBUG checks on unordered container local_iterator

Tests renamed as requested and I took the time to reduce code duplications in unordered_checks.h.     libstdc++: Add _GLIBCXX_DEBUG checks on unordered container local_iterator     Complete tests on  _GLIBCXX_DEBUG checks in include/debug/safe_local_iterator.h.     Fix several tests not te

Re: Re: [PATCH] Add COBOL to htdocs/gcc-15/changes.html.

Please adjust the text, there are too many people claiming NIST passing, but in case of gcobol - that's not true even if you ignore modules that are now obsolete or archaic. See my mail on how to run NIST with the GnuCOBOL setup - still too many failures. I hope that statement may be true in a

Re: [PATCH] RISC-V: Do not free a riscv_arch_string when handling target-arch attribute

On 2/26/25 1:46 AM, 翁愷邑 wrote: The build_target_option_node() function may return a cached node when fndecl having the same effective global_options. Therefore, freeing memory used in target nodes can lead to a use-after-free issue, as a target node may be shared by multiple fndecl. This issue

Re: [PATCH] Add COBOL information to gcc.gnu.org index.html

Robert Dubner writes: > Okay for htdocs/master? > > From d412e45d5afeecded3c8cf1b6b2865e088a480cc Mon Sep 17 00:00:00 2001 > From: Robert Dubner > Date: Thu, 17 Apr 2025 15:12:26 -0400 > Subject: [PATCH] Add COBOL information to gcc.gnu.org index.html > > * htdocs/index.html: Add COBOL inf

Re: [PATCH] doc: Use more precise cross-references for -ftrivial-auto-var-init

On 4/17/25 14:16, Jonathan Wakely wrote: On 11/03/25 17:39 +, Jonathan Wakely wrote: Add anchors for the hardbool and uninitialized attributes and then link directly to them. gcc/ChangeLog: * doc/extend.texi (Common Variable Attributes): Add @anchor to hardbool attribute. (Comm

Re: [PATCH] doc: Use more precise cross-references for -ftrivial-auto-var-init

On 11/03/25 17:39 +, Jonathan Wakely wrote: Add anchors for the hardbool and uninitialized attributes and then link directly to them. gcc/ChangeLog: * doc/extend.texi (Common Variable Attributes): Add @anchor to hardbool attribute. (Common Type Attributes): Add @anch

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

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 . OK for the trunk. I don't think it's worth porting to the release branches. jeff

RE: Re: [PATCH] Add COBOL to htdocs/gcc-15/changes.html.

I'll change it to "...much of the NIST test suite..." before I push it. > -Original Message- > From: Simon Sobisch > Sent: Thursday, April 17, 2025 15:11 > To: rdub...@symas.com > Cc: gcc-patches@gcc.gnu.org > Subject: Re: Re: [PATCH] Add COBOL to htdocs

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

On Thu, 17 Apr 2025, Tobias Burnus wrote: > Anyone: comments are welcome. > + The standard C++ library (libstdc++) is now supported I wouldn't mark up libstdc++ as in this context; we are pretty much treating it as a proper name/project name. (Two occurrences.) Looks good to me otherwise, t

Re: [PATCH] Add _GLIBCXX_DEBUG checks on unordered container local_iterator

On Thu, 17 Apr 2025 at 17:22, François Dumont wrote: > > Tests renamed as requested and I took the time to reduce code > duplications in unordered_checks.h. > > libstdc++: Add _GLIBCXX_DEBUG checks on unordered container > local_iterator > > Complete tests on _GLIBCXX_DEBUG checks in >

Re: [PATCH] libstdc++: Correct preprocessing checks for floatX_t and bfloat_16 formatting

On Thu, 17 Apr 2025 at 07:06, Tomasz Kaminski wrote: > > > > On Wed, Mar 12, 2025 at 1:00 PM Jonathan Wakely wrote: >> >> On Tue, 11 Mar 2025 at 12:22, Tomasz Kamiński wrote: >> > >> > Floating points types _Float16, _Float32, _Float64, and bfloat16, >> > can be formatted only if std::to_chars ov

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

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 Grosheintz wrote: This implements std::extents from acco

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

Gerald Pfeifer wrote: On Thu, 17 Apr 2025, Tobias Burnus wrote: * https://gcc.gnu.org/projects/gomp/ This is a no-brainer. Well, it still adds GCC 16 … It does make me wonder whether we really need/want distinct docs for minor releases or shouldn't better keep just one for the branch? I

Re: Add sse_fp_cost into i386_rtx_costs

> On Thu, 17 Apr 2025, Jan Hubicka wrote: > > > 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 > > f

Re: [pushed] c++: ill-formed constexpr function [PR113360]

On Wed, 16 Apr 2025, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > If we already gave an error while parsing a function, we don't also need to > try to explain what's wrong with it when we later try to use it in a > constant-expression. In the new testca

Re: Add sse_fp_cost into i386_rtx_costs

On Thu, 17 Apr 2025, Jan Hubicka wrote: > 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 com

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

On 17/04/2025 15:10, Tobias Burnus wrote: Hi all, @Fortraners: Comments to the added 'do concurrent' item? @Thomas: Are you fine with this C++ wording? @Andrew: Likewise for C++ and ROCm bump? This part is fine with me. Andrew Anyone: comments are welcome. Affected pages: * https://gcc.

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

On Thu, 17 Apr 2025 at 13:14, Tomasz Kaminski wrote: > > 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 tupl

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

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 makes use of teams and not only smoke tests it. T

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Hello, On Tue, 15 Apr 2025, Bill Wendling wrote: > > [... the horrors ...] > > All of this horribleness is because of the insistence of allowing for > primary expressions in the attributes, which I find to be a horrible > idea. I whole-heartedly agree with you :) But in light of this insistence

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

On Thu, Apr 17, 2025 at 2:10 PM Eric Botcazou wrote: > > > That looks like a good place - can we possibly say sth about signedness a > > well? IIRC all languages have unsigned bools but vector mask components are > > signed bools? > > Not really the right person to answer the above second ? I'm af

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

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 towards PR107761. If an extent changes its type, there's

Re: [PATCH] stdc++: Fixed signed comparision in _M_parse_fill_and_align [PR119840]

Subject line has "stdc++" instead of "libstdc++" On Thu, 17 Apr 2025 at 10:14, Tomasz Kamiński wrote: > > Explicitly cast elements of __not_fill to _CharT. Only '{' and ':' > are are used as `__not_fill`, so they are never negative. "are are" > > PR libstdc++/119840 > > libstdc++-v3/Cha

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

On Thu, Apr 17, 2025 at 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 towards PR107761. >> >> If an extent changes its type, there's a precondition in the st

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

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 Grosheintz >> wrote: >> >>> This implements std::extents from according to N4950 and >>> contains partial progress towards PR1077

RE: [PATCH 3/3][GCC16-Stage-1] RISC-V: Add testcases for vec_duplicate + vadd.vv combine to vadd.vx

mail.com; jeffreya...@gmail.com; rdapp@gmail.com; Chen, Ken ; Liu, Hongtao ; Robin Dapp Subject: Re: [PATCH 3/3][GCC16-Stage-1] RISC-V: Add testcases for vec_duplicate + vadd.vv combine to vadd.vx Hi Pan, > I am not sure if we have some options additional to below, like > -march=generic, &g

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

On Thu, Apr 17, 2025 at 1:20 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] Fix wrong optimization of conditional expression with enumeration type

> That looks like a good place - can we possibly say sth about signedness a > well? IIRC all languages have unsigned bools but vector mask components are > signed bools? Not really the right person to answer the above second ? I'm afraid. diff --git a/gcc/tree.def b/gcc/tree.def index c4ad8d08f10

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

On Thu, 17 Apr 2025 at 07:06, Tomasz Kaminski wrote: > > > > On Fri, Mar 28, 2025 at 9:33 PM Jonathan Wakely wrote: >> >> On 28/03/25 16:31 +0100, Tomasz Kamiński wrote: >> >The formatters for chrono types defined the parse/format methods >> >as accepting unconstrained types, this in combination

Re: [PATCH] rx: avoid adding setpsw for rx_cmpstrn when len is const

> Thanks. I made some minor stylistic adjustments and pushed the change > to the trunk. Thanks! That's awesome, thanks so much! -- -keith signature.asc Description: PGP signature

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

On Thu, Apr 17, 2025 at 1:18 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.

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

The `v1` in the subject line is a copy-paste error while creating the subject line. This is the preceding patch series: https://gcc.gnu.org/pipermail/libstdc++/2025-April/060988.html On 4/17/25 1:16 PM, Luc Grosheintz wrote: The following changes were made since v2: * Implement the missing part

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

On Thu, Apr 17, 2025 at 10:19 AM Eric Botcazou wrote: > > > LGTM. I do wonder if this could be documented somewhere if not > > already. Because I suspect there are other places which miss that if > > TYPE_PRECISION are equal, you might still need a cast for boolean > > types. Maybe a helper functi

  1   2   3   4   5   6   7   8   9   10   >