RE: [PATCH 5/5] match.pd: Use splits in makefile and make configurable.

> -Original Message- > From: Jeff Law > Sent: Sunday, April 30, 2023 8:46 PM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; bonz...@gnu.org; nero...@gcc.gnu.org; > aol...@gcc.gnu.org; ralf.wildenh...@gmx.de > Subject: Re: [PATCH 5/5] match.pd: Use splits in makefile and make >

[PATCH] i386: Fix up handling of debug insns in STV [PR109676]

Hi! The following testcase ICEs because STV replaces there (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1 (nil)) with (debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1 (nil)) which is invalid because of the mode mismatch. STV has fix_debug_reg_uses

Re: [PATCH 02/10] arm: Fix vstrwq* backend + testsuite

Hi Andrea, Minor comments below: On 4/28/23 13:29, Andrea Corallo via Gcc-patches wrote: Hi all, this patch fixes the vstrwq* MVE instrinsics failing to emit the correct sequence of instruction due to a missing predicates. Also the nit: you have a typo, should be "predicate" immediate range

Re: [PATCH 09/10] arm testsuite: XFAIL or relax registers in some tests

Hi Stam! On 4/28/23 13:30, Andrea Corallo via Gcc-patches wrote: From: Stam Markianos-Wright Hi all, This is a simple testsuite tidy-up patch, addressing to types of errors: * The vcmp vector-scalar tests failing due to the compiler's preference of vector-vector comparisons, over vector-sca

[PATCH] libstdc++: Shut up -Wattribute-alias warning [PR109694]

Hi! I've followed what other files do, using attribute alias with not really matching function type (after all, it isn't really possible when it is a constructor), but seems I've missed it warns: ../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void std::ios_base_library_init()’

[PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

Hi! The following patch regenerates the ABI files (I've only changed the Linux files which were updated recently (last month)). Tested on x86_64-linux, ok for trunk and later 13.2? 2023-05-02 Jakub Jelinek * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update. * co

Re: [PATCH 02/10] arm: Fix vstrwq* backend + testsuite

Christophe Lyon writes: > Hi Andrea, > > Minor comments below: > > On 4/28/23 13:29, Andrea Corallo via Gcc-patches wrote: >> Hi all, >> this patch fixes the vstrwq* MVE instrinsics failing to emit the >> correct sequence of instruction due to a missing predicates. Also the > nit: you have a typo

Re: [PATCH] libstdc++: Shut up -Wattribute-alias warning [PR109694]

On Tue, 2 May 2023 at 09:42, Jakub Jelinek wrote: > Hi! > > I've followed what other files do, using attribute alias with not really > matching function type (after all, it isn't really possible when it is a > constructor), but seems I've missed it warns: > ../../../../../libstdc++-v3/src/c++98/io

RE: [PATCH 00/22] arm: New framework for MVE intrinsics

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 00/22] arm: New framework for MVE intrinsics > > Hi, > >

RE: [PATCH 01/22] arm: move builtin function codes into general numberspace

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 01/22] arm: move builtin function codes into general > num

Re: [aarch64] Code-gen for vector initialization involving constants

Prathamesh Kulkarni writes: > On Tue, 25 Apr 2023 at 16:29, Richard Sandiford > wrote: >> >> Prathamesh Kulkarni writes: >> > Hi Richard, >> > While digging thru aarch64_expand_vector_init, I noticed it gives >> > priority to loading a constant first: >> > /* Initialise a vector which is part-v

[PATCH 09/10] arm testsuite: XFAIL or relax registers in some tests

On 02/05/2023 09:28, Christophe Lyon wrote: Hi Stam! On 4/28/23 13:30, Andrea Corallo via Gcc-patches wrote: From: Stam Markianos-Wright Hi all, This is a simple testsuite tidy-up patch, addressing to types of errors: * The vcmp vector-scalar tests failing due to the compiler's preferenc

[PATCH] [i386] Fix testcases for emulated scatter

The following adjusts testcases where the pr88531 fail with -m32 because we do not consider MMX size vectorization there and the pr89618 runs into load/store cost differences with -m32. Tested on x86_64-unknown-linux-gnu, pushed. * gcc.target/i386/pr88531-2a.c: Skip scanning for ia32.

[PATCH] tree-optimization/109672 - properly check emulated plus during vect

The following refactors the check for emulated vector support for the cases of plus, minus and negate. In the PR we end up with a SImode plus, supported by the target but emulated and in this context fail to verify we are dealing with exactly word_mode. Bootstrapped and tested on x86_64-unknown-l

Re: [PATCH v5 07/10] vect: Verify that GET_MODE_NUNITS is a multiple of 2.

Michael Collison writes: > While working on autovectorizing for the RISCV port I encountered an issue > where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a > evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode), > where GET_MODE_NUNITS is equal to one. >

Re: [PATCH 02/10] arm: Fix vstrwq* backend + testsuite

Christophe Lyon writes: > Hi Andrea, > > Minor comments below: > > On 4/28/23 13:29, Andrea Corallo via Gcc-patches wrote: >> Hi all, >> this patch fixes the vstrwq* MVE instrinsics failing to emit the >> correct sequence of instruction due to a missing predicates. Also the > nit: you have a typo

Re: [aarch64] Code-gen for vector initialization involving constants

On Tue, 2 May 2023 at 14:56, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Tue, 25 Apr 2023 at 16:29, Richard Sandiford > > wrote: > >> > >> Prathamesh Kulkarni writes: > >> > Hi Richard, > >> > While digging thru aarch64_expand_vector_init, I noticed it gives > >> > priority

RE: [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq > > Thi

Re: [PATCH] OpenACC: Further attach/detach clause fixes for Fortran [PR109622]

On 29.04.23 12:57, Julian Brown wrote: This patch moves several tests introduced by the following patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html I believe you intent this as git log entry. Can you add ... commit r14-325-gcacf65d74463600815773255e8b82b4043432bd7 as

Re: [PATCH] libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc 13.2+ libstdc++.so.6 [PR108969]

Hi Jakub, > Bootstrapped/regtested on x86_64-linux, i686-linux and sparc-sun-solaris2.11 > > On the last one I've actually checked a version which had > defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but > init_priority attribute doesn't seem to be supported there and so I coul

Re: [aarch64] Code-gen for vector initialization involving constants

Prathamesh Kulkarni writes: > On Tue, 2 May 2023 at 14:56, Richard Sandiford > wrote: >> > [aarch64] Improve code-gen for vector initialization with single constant >> > element. >> > >> > gcc/ChangeLog: >> > * config/aarch64/aarc64.cc (aarch64_expand_vector_init): Tweak >> > condition >>

[PATCH] RISC-V: fix build issue with gcc 4.9.x

GCC should still build with GCC 4.8.3 or newer [1] using C++03 by default. But a recent change in RISC-V port introduced a C++11 feature "std::log2" [2]. Use log2 from the C header, without the namespace [3]. [1] https://gcc.gnu.org/install/prerequisites.html [2] https://gcc.gnu.org/git/?p=gcc.g

Re: [PATCH] target: [PR109657] (a ? -1 : 0) | b could be optimized better for aarch64

Andrew Pinski via Gcc-patches writes: > There is no canonical form for this case defined. So the aarch64 backend needs > a pattern to match both of these forms. > > The forms are: > (set (reg/i:SI 0 x0) > (if_then_else:SI (eq (reg:CC 66 cc) > (const_int 0 [0])) > (reg:SI 97

Re: [PATCH] MATCH: Port CLRSB part of builtin_zero_pattern

On Sun, Apr 30, 2023 at 11:13 PM Andrew Pinski via Gcc-patches wrote: > > This ports the clrsb builtin part of builtin_zero_pattern > to match.pd. A simple pattern to port. > > OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. > > gcc/ChangeLog: > > * match.pd (a != 0 ?

Re: [PATCH] PHIOPT: small refactoring of match_simplify_replacement.

On Sun, Apr 30, 2023 at 11:14 PM Andrew Pinski via Gcc-patches wrote: > > When I added diamond shaped form bb to match_simplify_replacement, > I copied the code to move the statement rather than factoring it > out to a new function. This does the refactoring to a new function > to avoid the duplic

Re: [PATCH] PHIOPT: Improve replace_phi_edge_with_variable for diamond shapped bb

On Sun, Apr 30, 2023 at 11:14 PM Andrew Pinski via Gcc-patches wrote: > > While looking at differences between what minmax_replacement > and match_simplify_replacement does. I noticed that they sometimes > chose different edges to remove. I decided we should be able to do > better and be able to r

Re: [PATCH 09/10] arm testsuite: XFAIL or relax registers in some tests

On 28/04/2023 17:54, Kyrylo Tkachov wrote: -Original Message- From: Andrea Corallo Sent: Friday, April 28, 2023 12:30 PM To: gcc-patches@gcc.gnu.org Cc: Kyrylo Tkachov ; Richard Earnshaw ; Stam Markianos-Wright Subject: [PATCH 09/10] arm testsuite: XFAIL or relax registers in some t

[PATCH (pushed)] docs: port documentation of VRP params

gcc/ChangeLog: * doc/invoke.texi: Update documentation based on param.opt file. --- gcc/doc/invoke.texi | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 2f40c58b21c..b92b8576027 100644 --- a/gcc/doc/invoke

Re: [aarch64] Code-gen for vector initialization involving constants

On Tue, 2 May 2023 at 17:32, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Tue, 2 May 2023 at 14:56, Richard Sandiford > > wrote: > >> > [aarch64] Improve code-gen for vector initialization with single > >> > constant element. > >> > > >> > gcc/ChangeLog: > >> > * config

Re: [committed] Convert xstormy16 to LRA

> On May 1, 2023, at 7:37 PM, Roger Sayle wrote: > > ... > The shiftsi.cc regression on xstormy16 is fixed by adding > -fno-split-wide-types. > In fact, if all the regression tests pass, I'd suggest that > flag_split_wide-types = false > should be the default on xstormy16 now that we've moved

[pushed] c++: Add testcase for already fixed PR [PR109506]

The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR. PR c++/109506 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template26.C: New test. --- gcc/testsuite/g++.dg/cpp0x/nsdmi-template26.C | 22 +++ 1 file changed, 22 insertions(+) create mode

Re: [aarch64] Code-gen for vector initialization involving constants

Prathamesh Kulkarni writes: > On Tue, 2 May 2023 at 17:32, Richard Sandiford > wrote: >> >> Prathamesh Kulkarni writes: >> > On Tue, 2 May 2023 at 14:56, Richard Sandiford >> > wrote: >> >> > [aarch64] Improve code-gen for vector initialization with single >> >> > constant element. >> >> > >>

RE: [committed] Convert xstormy16 to LRA

On 02 May 2023 13:40, Paul Koning wrote: > > On May 1, 2023, at 7:37 PM, Roger Sayle > wrote: > > > > ... > > The shiftsi.cc regression on xstormy16 is fixed by adding > > -fno-split-wide-types. > > In fact, if all the regression tests pass, I'd suggest that > > flag_split_wide-types = false sho

Ping: [PATCH v2] libcpp: Handle extended characters in user-defined literal suffix [PR103902]

May I please ping this one? Thanks... https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613247.html On Thu, Mar 2, 2023 at 6:21 PM Lewis Hyatt wrote: > > The PR complains that we do not handle UTF-8 in the suffix for a user-defined > literal, such as: > > bool operator ""_π (unsigned long long

Re: [committed] Convert xstormy16 to LRA

Hi! On Tue, May 02, 2023 at 02:18:43PM +0100, Roger Sayle wrote: > On 02 May 2023 13:40, Paul Koning wrote: > > > On May 1, 2023, at 7:37 PM, Roger Sayle > > wrote: > > > The shiftsi.cc regression on xstormy16 is fixed by adding > > > -fno-split-wide-types. > > > In fact, if all the regression te

Re: [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq

On 5/2/23 12:26, Kyrylo Tkachov wrote: Hi Christophe, -Original Message- From: Christophe Lyon Sent: Tuesday, April 18, 2023 2:46 PM To:gcc-patches@gcc.gnu.org; Kyrylo Tkachov; Richard Earnshaw; Richard Sandiford Cc: Christophe Lyon Subject: [PATCH 03/22] arm: [MVE intrinsics] Rework

[r14-358 Regression] FAIL: gcc.dg/cpp/undef2.c (test for warnings, line 9) on Linux/x86_64

On Linux/x86_64, e7ce7c4905fd254760b1cd187752a03bc0c148ba is the first bad commit commit e7ce7c4905fd254760b1cd187752a03bc0c148ba Author: Longjun Luo Date: Sun Apr 30 12:28:06 2023 -0600 [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__ caused FAIL: c-c++-common/cpp/

Re: [committed] Convert xstormy16 to LRA

> On May 2, 2023, at 9:18 AM, Roger Sayle wrote: > > > On 02 May 2023 13:40, Paul Koning wrote: >>> On May 1, 2023, at 7:37 PM, Roger Sayle >> wrote: >>> >>> ... >>> The shiftsi.cc regression on xstormy16 is fixed by adding >>> -fno-split-wide-types. >>> In fact, if all the regression tests

Re: [PATCH] Add emulated scatter capability to the vectorizer

Hi Richard, On Fri, 28 Apr 2023 at 14:41, Richard Biener via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > This adds a scatter vectorization capability to the vectorizer > without target support by decomposing the offset and data vectors > and then performing scalar stores in the order of vecto

[PATCH] release the sorted FDE array when deregistering a frame [PR109685]

The atomic fastpath bypasses the code that releases the sort array which was lazily allocated during unwinding. We now check after deregistering if there is an array to free. libgcc/ChangeLog: * unwind-dw2-fde.c: Free sort array in atomic fast path. --- libgcc/unwind-dw2-fde.c | 6 ++

Re: [PATCH] RISC-V: fix build issue with gcc 4.9.x

Hi Romain: Pushed to trunk, thanks for catching that, that's definitely should use log2 no matter C++03 or C++11, but I think GCC allows the usage of C++11 according to https://gcc.gnu.org/install/prerequisites.html :P On Tue, May 2, 2023 at 8:22 PM Romain Naour via Gcc-patches wrote: > > GCC s

[PATCH] do not tailcall __sanitizer_cov_trace_pc [PR90746]

When instrumentation is requested via -fsanitize-coverage=trace-pc, GCC emits calls to __sanitizer_cov_trace_pc callback into each basic block. This callback is supposed to be implemented by the user, and should be able to identify the containing basic block by inspecting its return address. Tailca

Re: [PATCH 00/22] arm: New framework for MVE intrinsics

On 5/2/23 11:18, Kyrylo Tkachov wrote: Hi Christophe, -Original Message- From: Christophe Lyon Sent: Tuesday, April 18, 2023 2:46 PM To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; Richard Earnshaw ; Richard Sandiford Cc: Christophe Lyon Subject: [PATCH 00/22] arm: New framework for

[PATCH] c++: Fix up VEC_INIT_EXPR gimplification after r12-7069

Hi! During patch backporting, I've noticed that while most cp_walk_tree calls with cp_fold_r callback callers were changed from &pset to cp_fold_data &data, the VEC_INIT_EXPR gimplifications has not, so it still passes just address of a hash_set and so if during the folding we ever touch data->fla

RE: [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, May 2, 2023 3:05 PM > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org; > Richard Earnshaw ; Richard Sandiford > > Subject: Re: [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq > > > > > On 5/2/23 12:26, Kyrylo Tkacho

Re: [PATCH v2] RISC-V: ICE for vlmul_ext_v intrinsic API

committed, thanks for the patch :) On Fri, Apr 28, 2023 at 6:37 PM Li, Pan2 via Gcc-patches wrote: > > Kindly ping for this ICE fix. > > Pan > > -Original Message- > From: Wang, Yanzhang > Sent: Wednesday, April 26, 2023 9:06 PM > To: gcc-patches@gcc.gnu.org > Cc: juzhe.zh...@rivai.ai; k

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Tue, 2 May 2023 at 09:45, Jakub Jelinek wrote: > Hi! > > The following patch regenerates the ABI files (I've only changed the > Linux files which were updated recently (last month)). > > Tested on x86_64-linux, ok for trunk and later 13.2? > OK, thanks. I currently get: FAIL: libstdc++-abi/a

Re: [PATCH] libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc 13.2+ libstdc++.so.6 [PR108969]

On Fri, 28 Apr 2023 at 23:02, Jakub Jelinek wrote: > On Fri, Apr 28, 2023 at 09:35:49AM +0100, Jonathan Wakely wrote: > > Yes, for both, thanks for the fix. > > > > After it lands on the gcc-13 branch I'll also update the manual with: > > > > --- a/libstdc++-v3/doc/xml/manual/abi.xml > > +++ b/li

Re: [PATCH] RISC-V: fix build issue with gcc 4.9.x

On 5/2/23 08:31, Kito Cheng via Gcc-patches wrote: Hi Romain: Pushed to trunk, thanks for catching that, that's definitely should use log2 no matter C++03 or C++11, but I think GCC allows the usage of C++11 according to https://gcc.gnu.org/install/prerequisites.html :P Yes, we should be able

Re: [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq

On 5/2/23 17:28, Kyrylo Tkachov wrote: -Original Message- From: Christophe Lyon Sent: Tuesday, May 2, 2023 3:05 PM To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org; Richard Earnshaw ; Richard Sandiford Subject: Re: [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq On 5/2/23

Re: [committed] Convert xstormy16 to LRA

On Tue, May 02, 2023 at 10:11:27AM -0400, Paul Koning wrote: > > On May 2, 2023, at 9:18 AM, Roger Sayle wrote: > > Yes, see the section -fsplit-wide-types in > > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > Thanks. So I'm wondering why that would be a problem. > > The obvious q

Re: [PATCH] RISC-V: Name newly added flags in changelog

On 5/1/23 10:10, Patrick O'Neill wrote: This patch fixes the changelog to explicitly name the added command line flags introduced in this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616807.html 2023-05-01 Patrick O'Neill gcc/ChangeLog: * ChangeLog: Name the flags ad

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Tue, May 02, 2023 at 04:42:52PM +0100, Jonathan Wakely wrote: > On Tue, 2 May 2023 at 09:45, Jakub Jelinek wrote: > > > Hi! > > > > The following patch regenerates the ABI files (I've only changed the > > Linux files which were updated recently (last month)). > > > > Tested on x86_64-linux, ok

Re: [PATCH] RISC-V: fix build issue with gcc 4.9.x

> > Pushed to trunk, thanks for catching that, that's definitely should > > use log2 no matter C++03 or C++11, > > but I think GCC allows the usage of C++11 according to > > https://gcc.gnu.org/install/prerequisites.html :P > Yes, we should be able to use C++11. I'd like to get that to C++17 at >

[PATCH] rs6000: Add builtins for IEEE 128-bit floating point values

GCC maintainers: The following patch adds three buitins for inserting and extracting the exponent and significand for an IEEE 128-bit floating point values. The builtins are valid for Power 9 and Power 10. The patch has been tested on both Power 9 and Power 10. Please let me know if this patc

Re: [committed] Convert xstormy16 to LRA

On 5/1/23 17:37, Roger Sayle wrote: Jeff Law wrote: This patch converts the xstormy16 patch to LRA. It introduces a code quality regression in the shiftsi testcase, but it also fixes numerous aborts/errors. IMHO it's a good tradeoff. I've investigated the shiftsi regression on xstormy16

Re: [PATCH v5 06/11] RISC-V: Strengthen atomic stores

Discussed in the patchworks meeting with Jeff Law and decided to move forward with the trailing fence compatibility approach. If the trailing fence becomes a performance issue and people want to generate A.6 code, we'll need a PSABI change to identify which mapping a binary uses. We'll cross that

RE: [PATCH 04/22] arm: [MVE intrinsics] Rework vuninitialized

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 04/22] arm: [MVE intrinsics] Rework vuninitialized > > Implement vunin

RE: [PATCH 05/22] arm: [MVE intrinsics] add binary_opt_n shape

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 05/22] arm: [MVE intrinsics] add binary_opt_n shape > > This patch add

RE: [PATCH 06/22] arm: [MVE intrinsics] add unspec_based_mve_function_exact_insn

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 06/22] arm: [MVE intrinsics] add > unspec_based_mve_function_exact_insn

RE: [PATCH 07/22] arm: [MVE intrinsics] factorize vadd vsubq vmulq

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 07/22] arm: [MVE intrinsics] factorize vadd vsubq vmulq > > In order t

RE: [committed] Convert xstormy16 to LRA

On 02 May 2023 14:49, Segher Boessenkool wrote: > On Tue, May 02, 2023 at 02:18:43PM +0100, Roger Sayle wrote: > > On 02 May 2023 13:40, Paul Koning wrote: > > > > On May 1, 2023, at 7:37 PM, Roger Sayle > > > > > > > wrote: > > > > The shiftsi.cc regression on xstormy16 is fixed by adding > > >

Re: [PATCH 07/22] arm: [MVE intrinsics] factorize vadd vsubq vmulq

On 5/2/23 18:19, Kyrylo Tkachov wrote: -Original Message- From: Christophe Lyon Sent: Tuesday, April 18, 2023 2:46 PM To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; Richard Earnshaw ; Richard Sandiford Cc: Christophe Lyon Subject: [PATCH 07/22] arm: [MVE intrinsics] factorize vadd

Re: [PATCH] RISC-V: Name newly added flags in changelog

On 5/2/23 08:50, Jeff Law wrote: On 5/1/23 10:10, Patrick O'Neill wrote: This patch fixes the changelog to explicitly name the added command line flags introduced in this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616807.html 2023-05-01 Patrick O'Neill gcc/ChangeLog: * C

Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to VMSET

On 4/29/23 19:40, Kito Cheng wrote: Hi Jeff: The RTL pattern already models tail element and vector length well, so I don't feel the first version of Pan's patch has any problem? Input RTL pattern: #(insn 10 7 12 2 (set (reg:VNx2BI 134 [ _1 ]) #(if_then_else:VNx2BI (unspec:VNx2BI [

RE: [PATCH 08/22] arm: [MVE intrinsics] rework vaddq vmulq vsubq

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 08/22] arm: [MVE intrinsics] rework vaddq vmulq vsubq > > Implement va

RE: [PATCH 09/22] arm: [MVE intrinsics] add binary shape

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 09/22] arm: [MVE intrinsics] add binary shape > > This patch adds the

RE: [PATCH 10/22] arm: [MVE intrinsics] factorize vandq veorq vorrq vbicq

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 10/22] arm: [MVE intrinsics] factorize vandq veorq vorrq > vbicq > > F

RE: [PATCH 11/22] arm: [MVE intrinsics] rework vandq veorq

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 11/22] arm: [MVE intrinsics] rework vandq veorq > > Implement vamdq, v

RE: [PATCH 12/22] arm: [MVE intrinsics] add binary_orrq shape

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 12/22] arm: [MVE intrinsics] add binary_orrq shape > > patch adds the

Re: [committed] Enable LRA on several ports

On 5/1/23 21:24, Hans-Peter Nilsson via Gcc-patches wrote: There may be minor code quality regressions or there may be minor code quality improvements -- I'm leaving that for the port maintainers to own going forward. Right; I noticed performance regressions, and didn't want to commit

RE: [PATCH 13/22] arm: [MVE intrinsics] rework vorrq

> -Original Message- > From: Christophe Lyon > Sent: Tuesday, April 18, 2023 2:46 PM > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw ; Richard Sandiford > > Cc: Christophe Lyon > Subject: [PATCH 13/22] arm: [MVE intrinsics] rework vorrq > > Implement vorrq using th

[RFC,patch] Linker plugin - extend API for offloading corner case (aka: LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128])

See also https://gcc.gnu.org/PR109128 (+ description in the patch log) The linker plugin API was designed to handle LTO - such that the compiler (i.e. GCC's lto-plugin) can claim an input file if it finds LTO code. In that case, the symbols inside that file are ignored by 'ld'. However, GCC al

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

On Tue, May 02, 2023 at 05:50:17PM +0200, Jakub Jelinek via Gcc-patches wrote: > On Tue, May 02, 2023 at 04:42:52PM +0100, Jonathan Wakely wrote: > > On Tue, 2 May 2023 at 09:45, Jakub Jelinek wrote: > > > > > Hi! > > > > > > The following patch regenerates the ABI files (I've only changed the >

Re: [PATCH] c++: Move -Wdangling-reference to -Wextra [PR109642]

On 5/1/23 19:54, Marek Polacek wrote: Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users

Re: [PATCH 1/2] c++: potentiality of templated memfn call [PR109480]

On 5/1/23 15:59, Patrick Palka wrote: Here we're incorrectly deeming the templated call a.g() inside b's initializer as potentially constant, despite g being non-constexpr, which leads to us wastefully instantiating the initializer ahead of time and triggering a bug in access checking deferral (w

Re: [PATCH 2/2] c++: non-dep init folding and access checking [PR109480]

On 5/1/23 15:59, Patrick Palka wrote: enforce_access currently inspects processing_template_decl to determine whether to defer the given access check until instantiation time. But using this flag is unreliable because it gets cleared during e.g. non-dependent initializer folding, and can lead to

Re: [PATCH] c++: Fix up VEC_INIT_EXPR gimplification after r12-7069

On 5/2/23 11:19, Jakub Jelinek wrote: Hi! During patch backporting, I've noticed that while most cp_walk_tree calls with cp_fold_r callback callers were changed from &pset to cp_fold_data &data, the VEC_INIT_EXPR gimplifications has not, so it still passes just address of a hash_set and so if du

Re: [PATCH 1/2] c++: potentiality of templated memfn call [PR109480]

On Tue, 2 May 2023, Jason Merrill wrote: > On 5/1/23 15:59, Patrick Palka wrote: > > Here we're incorrectly deeming the templated call a.g() inside b's > > initializer as potentially constant, despite g being non-constexpr, > > which leads to us wastefully instantiating the initializer ahead of ti

Re: [PATCH 1/2] c++: potentiality of templated memfn call [PR109480]

on Tue, 2 May 2023, Patrick Palka wrote: > On Tue, 2 May 2023, Jason Merrill wrote: > > > On 5/1/23 15:59, Patrick Palka wrote: > > > Here we're incorrectly deeming the templated call a.g() inside b's > > > initializer as potentially constant, despite g being non-constexpr, > > > which leads to u

[Committed 01/11] RISC-V: Eliminate SYNC memory models

On 4/28/23 09:23, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: Remove references to MEMMODEL_SYNC_* models by converting via memmodel_base(). 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/riscv.cc: Remove MEMMODEL_SYNC_* cases and sanitize memmodel input with m

[Committed 02/11] RISC-V: Enforce Libatomic LR/SC SEQ_CST

On 4/28/23 09:50, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: Replace LR.aq/SC.rl pairs with the SEQ_CST LR.aqrl/SC.rl pairs recommended by table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill libgcc/ChangeLog: * config/riscv/atomic.c: Change LR.aq/SC.rl pairs into   

[Committed 03/11] RISC-V: Enforce subword atomic LR/SC SEQ_CST

On 4/27/23 09:22, Patrick O'Neill wrote: Replace LR.aq/SC.rl pairs with the SEQ_CST LR.aqrl/SC.rl pairs recommended by table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/sync.md: Change LR.aq/SC.rl pairs into sequentially consistent LR.aqrl

[Committed 04/11] RISC-V: Enforce atomic compare_exchange SEQ_CST

On 4/28/23 10:23, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: This patch enforces SEQ_CST for atomic compare_exchange ops. Replace Fence/LR.aq/SC.aq pairs with SEQ_CST LR.aqrl/SC.rl pairs recommended by table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill gcc/ChangeLog:

[Committed 07/11] RISC-V: Eliminate AMO op fences

On 4/28/23 10:43, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: Atomic operations with the appropriate bits set already enfore release semantics. Remove unnecessary release fences from atomic ops. This change brings AMO ops in line with table A.6 of the ISA manual. 2023-04-27 Pa

Re: [PATCH v5 05/11] RISC-V: Add AMO release bits

On 4/28/23 10:34, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: This patch sets the relevant .rl bits on amo operations. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/riscv.cc (riscv_print_operand): change behavior of %A to include release bits. Capitalize

[Committed 08/11] RISC-V: Weaken LR/SC pairs

On 4/28/23 10:56, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: Introduce the %I and %J flags for setting the .aqrl bits on LR/SC pairs as needed. Atomic compare and exchange ops provide success and failure memory models. C++17 and later place no restrictions on the relative stre

[Committed 09/11] RISC-V: Weaken mem_thread_fence

On 4/28/23 11:00, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: This change brings atomic fences in line with table A.6 of the ISA manual. Relax mem_thread_fence according to the memmodel given. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/sync.md (mem_thread_

[Committed 06/11] RISC-V: Strengthen atomic stores

On 4/28/23 10:40, Jeff Law wrote: On 4/27/23 10:22, Patrick O'Neill wrote: This change makes atomic stores strictly stronger than table A.6 of the ISA manual. This mapping makes the overall patchset compatible with table A.7 as well. 2023-04-27 Patrick O'Neill PR 89835 Should be "PR

[Committed 10/11] RISC-V: Weaken atomic loads

On 4/28/23 11:04, Jeff Law wrote: On 4/27/23 10:23, Patrick O'Neill wrote: This change brings atomic loads in line with table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/sync.md (atomic_load): Implement atomic load mapping. OK. jeff Committe

[PATCH 2/2] c++: look for empty base at specific offset [PR109678]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While looking at the empty base handling for 109678, it occurred to me that we ought to be able to look for an empty base at a specific offset, not just in general. PR c++/109678 gcc/cp/ChangeLog: * cp-tree.h (lookup_base)

[PATCH 1/2] c++: std::variant slow to compile [PR109678]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here, when dealing with a class with a complex subobject structure, we would try and fail to find the relevant FIELD_DECL for an empty base before giving up. And we would do this at each level, in a combinatorially problematic way. Instead

[pushed] c++: less invalidate_class_lookup_cache

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In the testcase below, we push_to_top_level to instantiate f and g, and they can both use the previous_class_level cache from instantiating A. Wiping the cache in pop_from_top_level is not helpful; we'll do that in pushclass if needed. te

[Committed 11/11] RISC-V: Table A.6 conformance tests

Updated the amo/load/store/fence tests to use check-function-bodies to ensure ordering. This is especially important for Load/Store where we want to ensure the correct fence is emitted in the correct spot. Compare exchange & subword amo ops still use scan-assembler-times. The change to check-func

Re: [committed] RISCV: Inline subword atomic ops

Is this OK for a backport to GCC-13 as well? (with the whitespace fixes/changelog revision squashed into it) Patrick On 4/26/23 10:01, Patrick O'Neill wrote: Committed - I had to reformat the changelog so it would push and resolve a trivial merge conflict in riscv.opt. --- RISC-V has no supp

Re: [PATCH] doc: Describe behaviour of enums with fixed underlying type

On Thu, 27 Apr 2023 at 16:58, Marek Polacek wrote: > On Thu, Apr 27, 2023 at 12:16:34PM +0100, Jonathan Wakely via Gcc-patches > wrote: > > C2x adds the ability to give an enumeration type a fixed underlying > > type, as C++ already has. The -fshort-enums option alters the compiler's > > choice of

Re: [PATCH] RISC-V: fix build issue with gcc 4.9.x

Hi Kito, Le 02/05/2023 à 17:51, Kito Cheng a écrit : >>> Pushed to trunk, thanks for catching that, that's definitely should >>> use log2 no matter C++03 or C++11, >>> but I think GCC allows the usage of C++11 according to >>> https://gcc.gnu.org/install/prerequisites.html :P >> Yes, we should be

Re: [PATCH] target: [PR109657] (a ? -1 : 0) | b could be optimized better for aarch64

On Tue, May 2, 2023 at 5:23 AM Richard Sandiford via Gcc-patches wrote: > > Andrew Pinski via Gcc-patches writes: > > There is no canonical form for this case defined. So the aarch64 backend > > needs > > a pattern to match both of these forms. > > > > The forms are: > > (set (reg/i:SI 0 x0) > >

[PATCH] c++: satisfaction of non-dep member alias template-id

constraints_satisfied_p already carefully checks dependence of template arguments before proceeding with satisfaction, so the dependence check in instantiate_alias_template is unnecessary and overly conservative. Getting rid of it allows us to check satisfaction ahead of time in more cases as in th

[COMMITTED] tree-optimization: [PR109702] MATCH: Fix a ? func(a) : N patterns

I accidently messed up these patterns so the comparison against 0 and the arguments was not matching up when they need to be. I committed this as obvious after a bootstrap/test on x86_64-linux-gnu PR tree-optimization/109702 gcc/ChangeLog: * match.pd: Fix "a != 0 ? FUNC(a) : CST

  1   2   >