Re: [PATCH] rtl-optimization/113597 - recover base term for argument pointers

On Sun, 3 Mar 2024, Jeff Law wrote: > > > On 2/9/24 03:26, Richard Biener wrote: > > The following allows a base term to be derived from an existing > > MEM_EXPR, notably the points-to set of a MEM_REF base. For the > > testcase in the PR this helps RTL DSE elide stores to a stack > >

[PATCH] i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]

Hi! The Intel extended format has the various weird number categories, pseudo denormals, pseudo infinities, pseudo NaNs and unnormals. Those are not representable in the GCC real_value and so neither GIMPLE nor RTX VIEW_CONVERT_EXPR/SUBREG folding folds those into constants. As can be seen on

Re: [PATCH] i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]

On Mon, Mar 04, 2024 at 09:34:30AM +0100, Uros Bizjak wrote: > > --- gcc/config/i386/i386-expand.cc.jj 2024-03-01 14:56:34.120925989 +0100 > > +++ gcc/config/i386/i386-expand.cc 2024-03-03 18:41:08.278793046 +0100 > > @@ -451,6 +451,20 @@ ix86_expand_move (machine_mode mode, rtx > >

Re: [PATCH] i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]

On Mon, Mar 4, 2024 at 9:41 AM Jakub Jelinek wrote: > > On Mon, Mar 04, 2024 at 09:34:30AM +0100, Uros Bizjak wrote: > > > --- gcc/config/i386/i386-expand.cc.jj 2024-03-01 14:56:34.120925989 > > > +0100 > > > +++ gcc/config/i386/i386-expand.cc 2024-03-03 18:41:08.278793046 > > > +0100 >

[PATCH] arm: Force flag_pic for FDPIC

From: Fangrui Song -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable for FDPIC (absolute addressing for symbol references and no function descriptor). The sh port simply upgrades -fno-pic to -fpie by setting flag_pic. Let's follow suit. Link:

Re: [PATCH] i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]

On Mon, Mar 4, 2024 at 9:25 AM Jakub Jelinek wrote: > > Hi! > > The Intel extended format has the various weird number categories, > pseudo denormals, pseudo infinities, pseudo NaNs and unnormals. > Those are not representable in the GCC real_value and so neither > GIMPLE nor RTX

[PATCH] bitint: Fix tree node sharing bug [PR114209]

Hi! We ICE on the following testcase due to invalid tree sharing. The second hunk fixes that, the first one is from me looking around at other spots which might need end up with invalid tree sharing too. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-04 Jakub

Re: [PATCH] fwprop: Avoid volatile defines to be propagated

Hi Jeff, 在 2024/3/4 11:37, Jeff Law 写道: > Can the same thing happen with a volatile memory load?  I don't think that  > will be caught by the volatile_insn_p check. Yes, I think so. If the define rtx contains volatile memory references, it may hit the same problem. We may use volatile_refs_p

Re: [PATCH] LoongArch: Fix inconsistent description in *sge_

On Mon, 2024-03-04 at 11:03 +0800, Guo Jie wrote: > The constraint of op[1] is inconsistent with the output template. > > gcc/ChangeLog: > > * config/loongarch/loongarch.md > (define_insn "*sge_"): Fix inconsistency > error. > > --- >  gcc/config/loongarch/loongarch.md | 4 ++--

Re: [PATCH] bitint: Fix tree node sharing bug [PR114209]

On Mon, 4 Mar 2024, Jakub Jelinek wrote: > Hi! > > We ICE on the following testcase due to invalid tree sharing. > The second hunk fixes that, the first one is from me looking around at > other spots which might need end up with invalid tree sharing too. > > Bootstrapped/regtested on

Re: [PATCH v2] Draft|Internal-fn: Introduce internal fn saturation US_PLUS

On Sat, Mar 2, 2024 at 8:46 AM Li, Pan2 wrote: > > Hi Richard and Tamar, > > I have a try with DEF_INTERNAL_SIGNED_OPTAB_FN for SAT_ADD/SUB/MUL but meet > some problem when match.pd. > > For unsigned SAT_ADD = (x + y) | - ((x + y) < x), the match.pd can be > (bit_ior:c (plus:c@2 @0 @1) (negate

Re: [Patch] invoke.texi: Add note that -foffload= does not affect device detection

Hi, Sandra Loosemore wrote: On 3/1/24 17:29, Sandra Loosemore wrote: On 3/1/24 08:23, Tobias Burnus wrote: Aside: Shouldn't all the HTML documents start with a and before the table of content? Currently, it has:    Top (GNU libgomp) and the body starts with    Short Table of Contents I

Re: [PATCH] middle-end: Fix dominator information with loop duplication PR114197

On Fri, Mar 1, 2024 at 11:16 PM Edwin Lu wrote: > > When adding the new_preheader to the cfg, only the new_preheader's dominator > information is updated. If one of the new basic block's children was part > of the original cfg and adding new_preheader to the cfg introduces another > path > to

[PATCH] tree-optimization/114192 - scalar reduction kept live with early break vect

The following fixes a missing replacement of the reduction value used in the epilog, causing the scalar reduction to be kept live across the early break exit path. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/114192 * tree-vect-loop.cc

[PATCH] tree-optimization/114203 - wrong CLZ niter computation

For precision less than int we apply the adjustment to make it defined at zero after the adjustment to make it compute CLZ rather than CTZ. That's wrong. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/114203 * tree-ssa-loop-niter.cc

[committed] libgomp: Use void (*) (void *) rather than void (*)() for host_fn type [PR114216]

Hi! For the type of the target callbacks we use elsehwere void (*) (void *) and IMHO should use that for the reverse offload fallback as well (where the actual callback is emitted using the same code as for host fallback or device kernel entry routines), even when it is also ok to use void (*) ()

Re: [PATCH] arm: Fixed C23 call compatibility with arm-none-eabi

On 2024-03-01 15:58, Richard Earnshaw (lists) wrote: On 19/02/2024 09:13, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-13? Regtested on top of 945cb8490cb for arm-none-eabi, without any regression. Backporting to releases/gcc-13 will change -std=c23 to -std=c2x. Jakub has just

Re: [Patch] invoke.texi: Add note that -foffload= does not affect device detection

Hi Sandra, Sandra Loosemore wrote: On 3/1/24 08:23, Tobias Burnus wrote: Maybe the proposed wording will help others to avoid this pitfall. (Or is this superfluous as -foffload= is not much used and, even if, no one then remembers or finds this none?) Well, I spent a long time looking at

Re: [PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On 01/03/24 15:38 -0500, Jason Merrill wrote: On 3/1/24 14:24, Marek Polacek wrote: +@smallexample +template +[[gnu::no_dangling(std::is_reference_v)]] int foo (T& t) @{ I think this function should return a reference. The condition in the attribute can only ever be true if you call this

Re: [Patch] OpenMP: Reject non-const 'condition' trait in Fortran (was: [Patch] OpenMP: Handle DECL_ASSEMBLER_NAME with 'declare variant')

Hi Tobias! On 2024-02-13T18:31:02+0100, Tobias Burnus wrote: > --- a/gcc/fortran/openmp.cc > +++ b/gcc/fortran/openmp.cc > + /* Device number must be conforming, which includes > + omp_initial_device (-1) and omp_invalid_device (-4). */ > + if (property_kind ==

Re: CI for "Option handling: add documentation URLs"

On Sun, 2024-03-03 at 21:04 +0100, Mark Wielaard wrote: > Hi, > > On Sat, Feb 24, 2024 at 06:42:58PM +0100, Mark Wielaard wrote: > > On Thu, Feb 22, 2024 at 11:57:50AM +0800, YunQiang Su wrote: > > > Mark Wielaard 于2024年2月19日周一 06:58写道： > > > > So, I did try the regenerate-opt-urls locally, and

GCC 14.0.1 Status Report (2024-03-04)

Status == The GCC development branch which will become GCC 14 is still in regression and documentation fixes only mode (Stage 4). GCC 14.1 will be released when we reach the milestone of zero P1 regressions. We've been into regression fixing for a good month now and at least the pace of new

[PATCH] tree-optimization/114197 - unexpected if-conversion for vectorization

The following avoids lowering a volatile bitfiled access and in case the if-converted and original loops end up in different outer loops because of simplifcations enabled scrap the result since that is not how the vectorizer expects the loops to be laid out. Bootstrapped and tested on

Fix 201001011-1.c on H8

Excerpt from gcc.sum: [...] PASS: gcc.c-torture/execute/20101011-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O0 execution test PASS: gcc.c-torture/execute/20101011-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/execute/20101011-1.c -O1 execution

[PATCH] c++/modules: Implement P2615 'Meaningful Exports' [PR107688]

Bootstrapped and regtested on x86_64-pc-linux-gnu. This should probably wait for GCC 15 I suppose, but sending it in now in case there are any comments. -- >8 -- This clarifies which kinds of declarations may and may not be exported in various contexts. The patch additionally fixes up some small

[PATCH] lower-subreg: Fix ROTATE handling [PR114211]

Hi! On the following testcase, we have (insn 10 7 11 2 (set (reg/v:TI 106 [ h ]) (rotate:TI (reg/v:TI 106 [ h ]) (const_int 64 [0x40]))) "pr114211.c":8:5 1042 {rotl64ti2_doubleword} (nil)) before subreg1 and the pass decides to use (reg:DI 127 [ h ]) / (reg:DI 128 [ h+8

RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

Thanks Jeff for comments. > But in the case of a vector modes, we can usually reinterpret the > underlying bits in whatever mode we want and do any of the usual > operations on those bits. Yes, I think that is why we can allow vector mode in get_stored_val if my understanding is correct. And

RE: [PATCH v2] Draft|Internal-fn: Introduce internal fn saturation US_PLUS

Thanks Richard for comments. > I do wonder what the existing usadd patterns with integer vector modes > in various targets do? > Those define_insn will at least not end up in the optab set I guess, > so they must end up > being either unused or used by explicit gen_* (via intrinsic > functions?)

Re: [PATCH] LoongArch: Fix inconsistent description in *sge_

Thanks for the feedback. The comparison between a const_imm12_operand and (const_int 1) does indeed perform a universal process of constant folding before any tree based optimization. I will fix it in patch v2. 在 2024/3/4 下午5:18, Xi Ruoyao 写道: On Mon, 2024-03-04 at 11:03 +0800, Guo Jie

[PATCH] bitint: Handle BIT_FIELD_REF lowering [PR114157]

Hi! The following patch adds support for BIT_FIELD_REF lowering with large/huge _BitInt lhs. BIT_FIELD_REF requires mode argument first operand, so the operand shouldn't be any huge _BitInt. If we only access limbs from inside of BIT_FIELD_REF using constant indexes, we can just create a new

[PATCHv2] fwprop: Avoid volatile defines to be propagated

Hi, This patch tries to fix a potential problem which is raised by the patch for PR111267. The volatile asm operand tries to be propagated to a single set insn with the patch for PR111267. The volatile asm operand might be executed for multiple times if the define insn isn't eliminated after

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On Mon, Mar 04, 2024 at 07:14:54PM -0500, Patrick Palka wrote: > On Sat, 2 Mar 2024, Nathaniel Shead wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > -- >8 -- > > > > When streaming in a nested template-template parameter as in the > > attached testcase, we

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On Mon, Mar 04, 2024 at 10:07:33PM -0500, Patrick Palka wrote: > On Tue, 5 Mar 2024, Nathaniel Shead wrote: > > > On Mon, Mar 04, 2024 at 09:26:00PM -0500, Patrick Palka wrote: > > > On Tue, 5 Mar 2024, Nathaniel Shead wrote: > > > > > > > On Mon, Mar 04, 2024 at 07:14:54PM -0500, Patrick Palka

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On Mon, Mar 04, 2024 at 06:01:48PM -0500, Jason Merrill wrote: > On 3/2/24 01:54, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > -- >8 -- > > > > When streaming in a nested template-template parameter as in the > > attached testcase, we end up

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

On 3/1/24 11:24 AM, rep.dot@gmail.com wrote: Hi Jerry and Steve, On 29 February 2024 19:28:19 CET, Jerry D wrote: On 2/29/24 10:13 AM, Steve Kargl wrote: On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote: On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: And, just for my own

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On Tue, 5 Mar 2024, Nathaniel Shead wrote: > On Mon, Mar 04, 2024 at 09:26:00PM -0500, Patrick Palka wrote: > > On Tue, 5 Mar 2024, Nathaniel Shead wrote: > > > > > On Mon, Mar 04, 2024 at 07:14:54PM -0500, Patrick Palka wrote: > > > > On Sat, 2 Mar 2024, Nathaniel Shead wrote: > > > > > > > >

[PATCH] c++: Fix ICE diagnosing incomplete type of overloaded function set [PR98356]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- In the linked PR the result of 'get_first_fn' is a USING_DECL against the template parameter, to be filled in on instantiation. But we don't actually need to get the first set of the member functions: it's enough to know

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On Sat, 2 Mar 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > -- >8 -- > > When streaming in a nested template-template parameter as in the > attached testcase, we end up reaching the containing template-template > parameter in

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On Tue, 5 Mar 2024, Nathaniel Shead wrote: > On Mon, Mar 04, 2024 at 07:14:54PM -0500, Patrick Palka wrote: > > On Sat, 2 Mar 2024, Nathaniel Shead wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > > > -- >8 -- > > > > > > When streaming in a nested

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On Mon, Mar 04, 2024 at 09:26:00PM -0500, Patrick Palka wrote: > On Tue, 5 Mar 2024, Nathaniel Shead wrote: > > > On Mon, Mar 04, 2024 at 07:14:54PM -0500, Patrick Palka wrote: > > > On Sat, 2 Mar 2024, Nathaniel Shead wrote: > > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK

Re: [PATCH] i386: Guard noreturn no-callee-saved-registers optimization with -mnoreturn-no-callee-saved-registers [PR38534]

On Thu, Feb 29, 2024 at 2:20 PM Hongtao Liu wrote: > > On Wed, Feb 28, 2024 at 4:54 PM Jakub Jelinek wrote: > > > > Hi! > > > > Adding Hongtao and Honza into the loop as the ones who acked the original > > patch. > > > > The no_callee_saved_registers by default for noreturn functions change can

[PATCH, OpenACC 2.7, v2] Adjust acc_map_data/acc_unmap_data interaction with reference counters

Hi Thomas, On 2023/10/31 11:06 PM, Thomas Schwinge wrote: > A few comments, should be easy to work in: >> @@ -460,7 +461,7 @@ acc_unmap_data (void *h) >> the different 'REFCOUNT_INFINITY' cases, or simply separate >> 'REFCOUNT_INFINITY' values per different usage

Re: [PATCH] combine: Don't simplify paradoxical SUBREG on WORD_REGISTER_OPERATIONS [PR113010]

Hi Jeff, > On 2/26/24 17:17, Greg McGary wrote: >> The sign-bit-copies of a sign-extending load cannot be known until runtime on >> WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM >> load. See the fix for PR112758. >> 2024-02-22 Greg McGary >> PR

[PATCH] combine: Fix recent WORD_REGISTER_OPERATIONS check [PR113010]

On Mon, Mar 04, 2024 at 05:18:39PM +0100, Rainer Orth wrote: > > On 2/26/24 17:17, Greg McGary wrote: > >> The sign-bit-copies of a sign-extending load cannot be known until runtime > >> on > >> WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending > >> MEM > >> load. See the

[PATCH v2 12/13] aarch64: Add aarch64-w64-mingw32 target to libatomic

From: Zac Walker Date: Fri, 1 Mar 2024 02:23:45 +0100 Subject: [PATCH v2 12/13] aarch64: Add aarch64-w64-mingw32 target to libatomic libatomic/ChangeLog: * configure.tgt: Add aarch64-w64-mingw32 target. --- libatomic/configure.tgt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v2 11/13] aarch64: Build and add objects for Cygwin and MinGW for AArch64

From: Zac Walker Date: Tue, 20 Feb 2024 13:55:51 +0100 Subject: [PATCH v2 11/13] aarch64: Build and add objects for Cygwin and MinGW for AArch64 gcc/ChangeLog: * config.gcc: Build and add objects for Cygwin and MinGW. Add Cygwin and MinGW options to the target. ---

Re: [PATCH] vect: Fix integer overflow calculating mask

On 23/02/2024 15:13, Richard Biener wrote: On Fri, 23 Feb 2024, Jakub Jelinek wrote: On Fri, Feb 23, 2024 at 02:22:19PM +, Andrew Stubbs wrote: On 23/02/2024 13:02, Jakub Jelinek wrote: On Fri, Feb 23, 2024 at 12:58:53PM +, Andrew Stubbs wrote: This is a follow-up to the previous

Re: [PATCH] fwprop: Avoid volatile defines to be propagated

On 3/4/24 02:12, HAO CHEN GUI wrote: Hi Jeff, 在 2024/3/4 11:37, Jeff Law 写道: Can the same thing happen with a volatile memory load?  I don't think that will  be caught by the volatile_insn_p check. Yes, I think so. If the define rtx contains volatile memory references, it may hit the same

[PATCH v2 09/13] aarch64: Add SEH to machine_function

From: Zac Walker Date: Tue, 20 Feb 2024 18:10:08 +0100 Subject: [PATCH v2 09/13] aarch64: Add SEH to machine_function SEH is not enabled in aarch64-w64-mingw32 target yet. However, it is needed to be declared in machine_function for reusing winnt.cc. gcc/ChangeLog: *

[PATCH v2 13/13] Add aarch64-w64-mingw32 target to libgcc

From: Zac Walker Date: Mon, 12 Feb 2024 15:22:47 +0100 Subject: [PATCH v2 13/13] Add aarch64-w64-mingw32 target to libgcc Reuse MinGW definitions from i386 for libgcc. Move reused files to libgcc/config/mingw folder. libgcc/ChangeLog: * config.host: Add aarch64-w64-mingw32 target.

Re: [PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On Mon, Mar 04, 2024 at 11:00:18AM +, Jonathan Wakely wrote: > On 01/03/24 15:38 -0500, Jason Merrill wrote: > > On 3/1/24 14:24, Marek Polacek wrote: > > > +@smallexample > > > +template > > > +[[gnu::no_dangling(std::is_reference_v)]] int foo (T& t) @{ > > > > I think this function should

[PATCH v2 01/13] Introduce aarch64-w64-mingw32 target

>From 38efaf5ab1fa017622d10239fff2ca23d2d3fb82 Mon Sep 17 00:00:00 2001 From: Zac Walker Date: Fri, 1 Mar 2024 01:40:53 +0100 Subject: [PATCH v2 01/13] Introduce aarch64-w64-mingw32 target Add the initial aarch64-w64-mingw32 target for gcc. fixincludes/ChangeLog: * mkfixinc.sh: Extend

[PATCH v2 02/13] aarch64: The aarch64-w64-mingw32 target implements

From: Zac Walker Date: Fri, 1 Mar 2024 01:45:13 +0100 Subject: [PATCH v2 02/13] aarch64: The aarch64-w64-mingw32 target implements the MS ABI Two ABIs for aarch64 have been defined for different platforms. gcc/ChangeLog: * config/aarch64/aarch64-opts.h (enum aarch64_calling_abi):

[PATCH,V2] ctf: fix incorrect CTF for multi-dimensional array types

From: Cupertino Miranda [Changes from V1] - Refactor the code a bit. [End of changes from V1] PR debug/114186 DWARF DIEs of type DW_TAG_subrange_type are linked together to represent the information about the subsequent dimensions. The CTF processing was so far working through them in the

[PATCH v2 00/13] Add aarch64-w64-mingw32 target

Hello, v2 is ready for the review! Based on the v1 review: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#646203 Testing for the x86_64-w64-mingw32 target is in progress to avoid regression due to refactoring. Regards, Evgeny Changes from v1 to v2: Adjust the target name

[PATCH v2 04/13] aarch64: Add aarch64-w64-mingw32 COFF

From: Zac Walker Date: Fri, 1 Mar 2024 01:55:47 +0100 Subject: [PATCH v2 04/13] aarch64: Add aarch64-w64-mingw32 COFF Define ASM specific for COFF format on AArch64. gcc/ChangeLog: * config.gcc: Add COFF format support definitions. * config/aarch64/aarch64-coff.h: New file. ---

[PATCH v2 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

From: Zac Walker Date: Fri, 1 Mar 2024 09:56:59 +0100 Subject: [PATCH v2 03/13] aarch64: Mark x18 register as a fixed register for MS ABI Define the MS ABI for aarch64-w64-mingw32. Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and STATIC_CHAIN_REGNUM for AArch64 MS ABI. The X18 register is

[PATCH v2 07/13] Exclude i386 functionality from aarch64 build

From: Zac Walker Date: Fri, 1 Mar 2024 02:35:40 +0100 Subject: [PATCH v2 07/13] Exclude i386 functionality from aarch64 build This patch defines TARGET_AARCH64_MS_ABI in config.gcc and uses it to exclude i386 functionality from aarch64 build and adjust MinGW headers for AArch64 MS ABI.

[PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

From: Zac Walker Date: Fri, 1 Mar 2024 10:49:28 +0100 Subject: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64 Define Cygwin and MinGW environment such as types, SEH definitions, shared libraries, etc. gcc/ChangeLog: * config.gcc: Add Cygwin and MinGW

[PATCH v2 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW Options"

From: Zac Walker Date: Fri, 1 Mar 2024 02:17:39 +0100 Subject: [PATCH v2 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW Options" Rename "x86 Windows Options" to "Cygwin and MinGW Options". It will be used also for AArch64. gcc/ChangeLog: * config/i386/mingw-w64.opt.urls:

[PATCH v2 00/13] Add aarch64-w64-mingw32 target

gcc/ChangeLog: * config.gcc: * config/aarch64/aarch64-opts.h (enum aarch64_calling_abi): * config/aarch64/aarch64-protos.h (mingw_pe_maybe_record_exported_symbol): (mingw_pe_section_type_flags): (mingw_pe_unique_section):

Re: [PATCH] vect: Fix integer overflow calculating mask

On Mon, Mar 04, 2024 at 03:30:01PM +, Andrew Stubbs wrote: > vect: Fix integer overflow calculating mask > > The masks and bitvectors were broken when nunits==32 on hosts where int is > 32-bit. > > gcc/ChangeLog: > > * dojump.cc (do_compare_and_jump): Use full-width integers for

[PATCH v2 05/13] Reuse MinGW from i386 for AArch64

From: Zac Walker Date: Fri, 1 Mar 2024 02:41:50 +0100 Subject: [PATCH v2 05/13] Reuse MinGW from i386 for AArch64 This patch creates a new config/mingw directory to share MinGW related definitions, and moves there the corresponding existing files from config/i386. gcc/ChangeLog: *

[PATCH] bpf: add inline memset expansion

Similar to memmove and memcpy, the BPF backend cannot fall back on a library call to implement __builtin_memset, and should always expand calls to it inline if possible. This patch implements simple inline expansion of memset in the BPF backend in a verifier-friendly way. Similar to memcpy and

Re: [PATCH] combine: Fix recent WORD_REGISTER_OPERATIONS check [PR113010]

On 3/4/24 09:49, Jakub Jelinek wrote: On Mon, Mar 04, 2024 at 05:18:39PM +0100, Rainer Orth wrote: On 2/26/24 17:17, Greg McGary wrote: The sign-bit-copies of a sign-extending load cannot be known until runtime on WORD_REGISTER_OPERATIONS targets, except in the case of a zero-extending MEM

[PATCH v2 06/13] Rename section and encoding functions from i386 which will be used in aarch64

From: Zac Walker Date: Tue, 20 Feb 2024 17:22:31 +0100 Subject: [PATCH v2 06/13] Rename section and encoding functions from i386 which will be used in aarch64 gcc/ChangeLog: * config/i386/cygming.h (SUBTARGET_ENCODE_SECTION_INFO): Rename functions in mingw folder which will be

Re: [PATCH] c++: lambda capturing structured bindings [PR85889]

On Fri, Mar 01, 2024 at 07:58:24PM -0500, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? (Or even trunk?) > > -- >8 -- > clarifies that it's OK to capture structured > bindings. > > [expr.prim.lambda.capture]/4 says "The identifier

Re: [PATCH,V2] ctf: fix incorrect CTF for multi-dimensional array types

Hi Indu, Cupertino, On 3/4/24 10:00, Indu Bhagat wrote: > From: Cupertino Miranda > > [Changes from V1] > - Refactor the code a bit. > [End of changes from V1] > > PR debug/114186 > > DWARF DIEs of type DW_TAG_subrange_type are linked together to represent > the information about the

Re: [PATCH] bpf: add inline memset expansion

Hi David. Thanks for the patch. OK. > Similar to memmove and memcpy, the BPF backend cannot fall back on a > library call to implement __builtin_memset, and should always expand > calls to it inline if possible. > > This patch implements simple inline expansion of memset in the BPF > backend in

[PATCH] middle-end/113680 - Optimize (x - y) CMP 0 as x CMP y

(x - y) CMP 0 is equivalent to x CMP y where x and y are signed integers and CMP is <, <=, >, or >=. Similarly, 0 CMP (x - y) is equivalent to y CMP x. As reported in PR middle-end/113680, this equivalence does not hold for types other than signed integers. When it comes to conditions, the

Re: [PATCH] c++/modules: Support exporting using-decls in same namespace as target

On 3/3/24 18:11, Nathaniel Shead wrote: Came across this issue while working on another PR. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Or otherwise for GCC 15? OK. -- >8 -- Currently a using-declaration bringing a name into its own namespace is a no-op, except for

[PATCH] c++/modules: member alias tmpl partial inst [PR103994]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Alias templates are weird in that their specializations can appear in both decl_specializations and type_specializations. They appear in the latter only at parse time via finish_template_type. This should

[PATCH v2 00/13] Add aarch64-w64-mingw32 target

Zac Walker (13): Introduce aarch64-w64-mingw32 target aarch64: The aarch64-w64-mingw32 target implements the MS ABI aarch64: Mark x18 register as a fixed register for MS ABI aarch64: Add aarch64-w64-mingw32 COFF Reuse MinGW from i386 for AArch64 Rename section and encoding functions

[PATCH v2] middle-end/113680 - Optimize (x - y) CMP 0 as x CMP y

(x - y) CMP 0 is equivalent to x CMP y where x and y are signed integers and CMP is <, <=, >, or >=. Similarly, 0 CMP (x - y) is equivalent to y CMP x. As reported in PR middle-end/113680, this equivalence does not hold for types other than signed integers. When it comes to conditions, the

Re: [PATCH] c++: DECL_DECOMPOSITION_P cleanup

On 3/1/24 19:59, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? OK for 15, yes. -- >8 -- DECL_DECOMPOSITION_P already checks VAR_P but we repeat the check in a lot of places. gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Don't check VAR_P before

Re: [PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

On 3/2/24 01:54, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- When streaming in a nested template-template parameter as in the attached testcase, we end up reaching the containing template-template parameter in 'tpl_parms_fini'. We should not

[PATCH] c++: ICE with variable template and [[deprecated]] [PR110031]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- lookup_and_finish_template_variable already has and uses the complain parameter but it is not passing it down to mark_used so we got the default tf_warning_or_error, which causes various problems when