[RISC-V] RISC-V: Add implication for M extension.

From 114731cd9cf28ad313de05a507b7253fb9bef3cb Mon Sep 17 00:00:00 2001 From: Tsung Chun Lin Date: Tue, 8 Oct 2024 17:40:59 -0600 Subject: [RISC-V] RISC-V: Add implication for M extension. That M implies Zmmul. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: M implies Zmmul. gcc/testsui

Re: [PATCH v1 1/2] Match: Support form 2 for scalar signed integer SAT_TRUNC

On Wed, Oct 9, 2024 at 5:30 AM wrote: > > From: Pan Li > > This patch would like to support the form 2 of the scalar signed > integer SAT_TRUNC. Aka below example: > > Form 2: > #define DEF_SAT_S_TRUNC_FMT_2(NT, WT, NT_MIN, NT_MAX) \ > NT __attribute__((noinline)) \

Re: [PATCH v1 1/2] Match: Support form 4 for scalar signed integer SAT_TRUNC

On Thu, Oct 10, 2024 at 8:55 AM wrote: > > From: Pan Li > > This patch would like to support the form 4 of the scalar signed > integer SAT_TRUNC. Aka below example: > > Form 4: > #define DEF_SAT_S_TRUNC_FMT_4(NT, WT, NT_MIN, NT_MAX) \ > NT __attribute__((noinline)) \

Re: [PATCH v1 1/2] Match: Support form 3 for scalar signed integer SAT_TRUNC

On Wed, Oct 9, 2024 at 4:40 PM wrote: > > From: Pan Li > > This patch would like to support the form 3 of the scalar signed > integer SAT_TRUNC. Aka below example: > > Form 3: > #define DEF_SAT_S_TRUNC_FMT_3(NT, WT, NT_MIN, NT_MAX) \ > NT __attribute__((noinline)) \

Re: [PATCH v1 2/4] Vect: Try the pattern of vector signed integer SAT_SUB

On Fri, Oct 11, 2024 at 8:24 AM wrote: > > From: Pan Li > > Almost the same as vector unsigned integer SAT_SUB, try to match > the signed version during the vector pattern matching. > > The below test suites are passed for this patch. > * The rv64gcv fully regression test. > * The x86 bootstrap t

Re: [PATCH v1 1/4] Match: Support form 1 for vector signed integer SAT_SUB

On Fri, Oct 11, 2024 at 8:24 AM wrote: > > From: Pan Li > > This patch would like to support the form 1 of the vector signed > integer SAT_SUB. Aka below example: > > Form 1: > #define DEF_VEC_SAT_S_SUB_FMT_1(T, UT, MIN, MAX) \ > void __attribute__((noinline))

RE: [PATCH][PR113816] AArch64: Use SIMD+GPR for logical vector reductions

> -Original Message- > From: Richard Biener > Sent: Friday, October 11, 2024 7:52 AM > To: Richard Sandiford > Cc: Jennifer Schmitz ; gcc-patches@gcc.gnu.org; Richard > Earnshaw ; Kyrylo Tkachov > ; Tamar Christina > Subject: Re: [PATCH][PR113816] AArch64: Use SIMD+GPR for logical vector

[PATCH] c: Implement C2Y N3355 - Named Loops [PR117022]

Hi! The following patch implements the C2Y N3355 - Named Loops paper. I've tried to implement it lazily, rather than proactively e.g. push labels to a vector just in case the following statement is iteration statement, switch statement or one of the loop pragmas followed by iteration statement th

RE: [PATCH]middle-end: support SLP early break

On Thu, 10 Oct 2024, Tamar Christina wrote: > > > e.g. if (a != 0) where a is loop invariant. For instance test_memcmp_1_1 > > > in /gcc.dg/memcmp-1.c is such loop. Technically we should be able to > > > vectorize such loops, but while we can represent externals in the SLP > > > tree, > > > we

RE: [PATCH][PR113816] AArch64: Use SIMD+GPR for logical vector reductions

On Fri, 11 Oct 2024, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Friday, October 11, 2024 7:52 AM > > To: Richard Sandiford > > Cc: Jennifer Schmitz ; gcc-patches@gcc.gnu.org; Richard > > Earnshaw ; Kyrylo Tkachov > > ; Tamar Christina > > Subject: R

RE: [PATCH]middle-end: support SLP early break

> -Original Message- > From: Richard Biener > Sent: Friday, October 11, 2024 8:11 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: RE: [PATCH]middle-end: support SLP early break > > On Thu, 10 Oct 2024, Tamar Christina wrote: > > > > > e.g. i

[PATCH] i386: Fix up spaceship expanders for -mtune=i[45]86 [PR117053]

Hi! The adjusted and new spaceship expanders ICE with -mtune=i486 or -mtune=i586. The problem is that in that case TARGET_ZERO_EXTEND_WITH_AND is true and zero_extendqisi2 isn't allowed in that case, and we can't use the replacement AND, because that clobbers flags and we want to use them again.

[PATCH 2/2] PR target/117048 aarch64: Use more canonical and optimization-friendly representation for XAR instruction

The pattern for the Advanced SIMD XAR instruction isn't very optimization-friendly at the moment. In the testcase from the PR once simlify-rtx has done its work it generates the RTL: (set (reg:V2DI 119 [ _14 ]) (rotate:V2DI (xor:V2DI (reg:V2DI 114 [ vect__1.12_16 ]) (reg:V2DI 116 [

[PATCH 1/2] PR 117048: simplify-rtx: Extend (x << C1) | (X >> C2) --> ROTATE transformation to vector operands

Hi all, In the testcase from patch [2/2] we want to match a vector rotate operation from an IOR of left and right shifts by immediate. simplify-rtx has code for just that but it looks like it's prepared to do handle only scalar operands. In practice most of the code works for vector modes as well

Re: [PATCH] middle-end: [PR middle-end/116926] Allow widening optabs for vec-mode -> scalar-mode

On Thu, Oct 10, 2024 at 5:25 PM Victor Do Nascimento wrote: > > The recent refactoring of the dot_prod optab to convert-type exposed a > limitation in how `find_widening_optab_handler_and_mode' is currently > implemented, owing to the fact that, while the function expects the > > GET_MODE_CLASS

Re: [PATCH] i386: Fix up spaceship expanders for -mtune=i[45]86 [PR117053]

On Fri, Oct 11, 2024 at 9:16 AM Jakub Jelinek wrote: > > Hi! > > The adjusted and new spaceship expanders ICE with -mtune=i486 or > -mtune=i586. > The problem is that in that case TARGET_ZERO_EXTEND_WITH_AND is true > and zero_extendqisi2 isn't allowed in that case, and we can't use > the replacem

Re: [to-be-committed][RISC-V] Slightly improve broadcasting small constants into vectors

On 10/11/24 5:40 PM, Andrew Waterman wrote: Whether or not we should use vmv.v.i vs vmv.s.x for loading [-16..15] into the 0th element is probably uarch dependent. The tradeoff is loading the GPR vs the broadcast in the vector unit. I didn't bother with this case. Note that this tradeoff i

Re: [to-be-committed][RISC-V] Slightly improve broadcasting small constants into vectors

On Fri, Oct 11, 2024 at 6:26 AM Jeff Law wrote: > > I probably spent way more time on this than it's worth... > > I was looking at the code we generate for vector SAD and noticed that we > were being a bit silly. Specifically: > > li a4,0# 272 [c=4 l=4] *movsi_interna

[PATCH] gcc.target/i386/invariant-ternlog-1.c: Also scan (%edx)

Since x32 uses (%edx), instead of (%rdx), also scan (%edx). * gcc.target/i386/invariant-ternlog-1.c: Also scan (%edx). -- H.J. From eb27c432407702cf18c460dac08696d80851e729 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Sat, 12 Oct 2024 05:04:33 +0800 Subject: [PATCH] gcc.target/i386/invariant

Re: [PATCH v1 3/4] RISC-V: Implement vector SAT_SUB for signed integer

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2024-10-11 14:22 To: gcc-patches CC: richard.guenther; Tamar.Christina; juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li Subject: [PATCH v1 3/4] RISC-V: Implement vector SAT_SUB for signed integer From: Pan Li This patch would like to im

Re: [PATCH] [PR86710][PR116826] match.pd: Fold logarithmic identities.

> On 8 Oct 2024, at 10:44, Richard Biener wrote: > > External email: Use caution opening links or attachments > > > On Thu, 3 Oct 2024, Jennifer Schmitz wrote: > >> >> >>> On 1 Oct 2024, at 14:27, Richard Biener wrote: >>> >>> External email: Use caution opening links or attachments >>>

[PATCH] SVE intrinsics: Fold svmul with constant power-of-2 operand to svlsl

Previously submitted in https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663435.html For svmul, if one of the operands is a constant vector with a uniform power of 2, this patch folds the multiplication to a left-shift by immediate (svlsl). Because the shift amount in svlsl is the second

[PATCH] gcc.target/i386/pr53533-[13].c: Adjust assembly scan

Before 1089d083117 Simplify (B * v + C) * D -> BD* v + CD when B,C,D are all INTEGER_CS T. the loop was .L2: movl (%rdi,%rdx), %eax addl $12345, %eax imull $-1564285888, %eax, %eax leal -333519936(%rax), %eax movl %eax, (%rsi,%rdx) addq $4, %rdx cmpq $1024, %rdx jne .L2 There were 1 addl and 1

[PATCH] gcc.target/i386/pr55583.c: Use long long for 64-bit integer

Since long is 32-bit for x32, use long long for 64-bit integer. * gcc.target/i386/pr55583.c: Use long long for 64-bit integer. -- H.J. From 97a61d75d338ce330f411fa0058949c4346b7119 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Sat, 12 Oct 2024 06:15:28 +0800 Subject: [PATCH] gcc.target/i386/p

[PATCH] gcc.target/i386/pr115749.c: Use word_mode integer

Use word_mode integer with func so that 64-bit integer is used with x32. * gcc.target/i386/pr115749.c (uword): New. (func): Replace unsigned long with uword. -- H.J. From bef1df8952cb373dda768c5370fd70479b7ba785 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Sat, 12 Oct 2024 05:22:52 +0800 Subj

[Patch] Fortran: Unify gfc_get_location handling; fix expr->ts bug

This unifies the two locus to location_t conversion functions, preparing for some changes I want to do later. In principle, I had the patch this morning; however, the assert is now exercised more often than before - and it triggered rather unexpected when running the testsuite. Turned out th

RE: [PATCH v1 1/4] Match: Support form 1 for vector signed integer SAT_SUB

Thanks Richard for explaining. > Yes. The different variants seem to have different complexity and generic > expansion might prefer one or another version. So I wasn't suggesting to > expand .SAT_ADD/SUB in the middle-end but instead canonicalize the open-coding > to the cheapest (smallest) vari

[PATCH] phiopt: Clobbers can sometimes get in the way of phiopt [PR117096]

Clobbers in a condition don't cause any improvements and are getting in the way of doing match and simplify with phiopt. Need to ignore/skip over them in when seeing if there is only one statement that can moved. Also since clobbers have vops, skipping over the vops phi node is needed to be done.

[PATCH] middle-end/117086 - fixup vec_cond simplifications

The following adds missing checks for a vector type result type to simplifications that end up creating a vec_cond. Bootstrap and regtest running on x86_64-unknown-linux-gnu. PR middle-end/117086 * match.pd ((op (vec_cond ...) ..) -> (vec_cond ...)): Add missing checks for

Re: Ping: [PATCH] d,ada/spec: only sub nostd{inc,lib} rather than nostd{inc,lib}*

Arsen Arsenović writes: > Ping on this patch. Hello Arsen, and sorry for taking so long to reply. The patch is OK for the Ada part. Cheers, Marc

Re: [PATCH] Add 'cobol' to Makefile.def

On Thu, Oct 10, 2024 at 9:07 PM James K. Lowden wrote: > > Hello, > > I just joined the list to begin contributing patches for the COBOL > front end we've been touting for the last 4 years. It's my first > attempt. Please tell me if you'd like to see something different. > > What follows mimics

Re: [PATCH] libgccjit: Add support for creating temporary variables

Hi, David. Can you please review the updated patch? Can I merge it? Thanks. Le 2024-02-29 à 16 h 11, Antoni Boucher a écrit : Hi and thanks for the review! Here's the updated patch. Le 2024-01-24 à 09 h 54, David Malcolm a écrit : On Fri, 2024-01-19 at 16:54 -0500, Antoni Boucher wrote: Hi. T

[PATCH] This is a test3, please ignore

CI-tag: skip -- >8 -- This is a test patch, please ignore. --- README | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README b/README index be15bc2b44e..7a3d7cfeb74 100644 --- a/README +++ b/README @@ -1,3 +1,5 @@ +THIS IS A TEST -- IGNORE + This directory contains the GNU Compiler Collec

Re: [PATCH][PR113816] AArch64: Use SIMD+GPR for logical vector reductions

> On 11 Oct 2024, at 12:08, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Tamar Christina writes: >>> -Original Message- >>> From: Richard Biener >>> Sent: Friday, October 11, 2024 7:52 AM >>> To: Richard Sandiford >>> Cc: Jennifer Schm

Re: [Patch] Fortran: Dead-function removal in error.cc (shrinking by 40%)

On Fri, 2024-10-11 at 15:34 +0100, Paul Richard Thomas wrote: > Hi Tobias, > > Good catch! It looks 'obvious' to me too :-) > > Regards > > Paul > > > On Fri, 11 Oct 2024 at 14:08, Tobias Burnus > wrote: > > > I found always error.cc rather confusing but I just realized that > > we can reduc

Re: [Patch] Fortran: Dead-function removal in error.cc (shrinking by 40%)

Hi Tobias, Good catch! It looks 'obvious' to me too :-) Regards Paul On Fri, 11 Oct 2024 at 14:08, Tobias Burnus wrote: > I found always error.cc rather confusing but I just realized that > we can reduce number of lines in that file by 40% - and remove a lot of > (apparent) complexity. > > T

Re: [PATCH] c++: Fix mangling of otherwise unattached class-scope lambdas [PR116568]

On 9/5/24 11:02 AM, Nathaniel Shead wrote: Bootstrapped and regtested (so far just dg.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest passes? Or would it be better to try to implement all the rules mentioned in the linked pull request for one commit; I admit I haven't looked very close

[committed] libstdc++: Add missing whitespace in dg-do directives

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * testsuite/22_locale/time_get/get/char/5.cc: Fix dg-do directive. * testsuite/22_locale/time_get/get/wchar_t/5.cc: Likewise. --- libstdc++-v3/testsuite/22_locale/time_get/get/char/5.cc| 2 +- lib

[committed] libstdc++: Use appropriate feature test macro for std::byte

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/bits/cpp_type_traits.h (__is_byte): Guard with __glibcxx_byte macro instead of checking __cplusplus. --- libstdc++-v3/include/bits/cpp_type_traits.h | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: [PATCH v3 2/5] openmp: Add support for iterators in map clauses (C/C++)

On Fri, Oct 04, 2024 at 03:56:01PM +0100, Kwok Cheung Yeung wrote: > This patch modifies the C and C++ parsers to accept an iterator as a map > type modifier, storing it in the OMP_CLAUSE_ITERATOR argument of the clause. > When finishing clauses, any clauses generated from a clause with iterators >

Re: [PATCH] middle-end: [PR middle-end/116926] Allow widening optabs for vec-mode -> scalar-mode

On 10/11/24 08:28, Richard Biener wrote: On Thu, Oct 10, 2024 at 5:25 PM Victor Do Nascimento wrote: The recent refactoring of the dot_prod optab to convert-type exposed a limitation in how `find_widening_optab_handler_and_mode' is currently implemented, owing to the fact that, while the funct

Re: [PATCH] libcpp, genmatch: Use gcc_diag instead of printf for libcpp diagnostics

On Fri, 13 Sep 2024, Jakub Jelinek wrote: > @@ -1533,7 +1536,7 @@ do_linemarker (cpp_reader *pfile) >/* Unlike #line, there does not seem to be a way to get an EOF >here. So, it should be safe to always spell the token. */ >cpp_error (pfile, CPP_DL_ERROR, > -

[PATCH v2] middle-end: [PR middle-end/116926] Allow widening optabs for vec-mode -> scalar-mode

The recent refactoring of the dot_prod optab to convert-type exposed a limitation in how `find_widening_optab_handler_and_mode' is currently implemented, owing to the fact that, while the function expects the GET_MODE_CLASS (from_mode) == GET_MODE_CLASS (to_mode) condition to hold, the c6x back

Re: [PATCH][aarch64][libstdc++] Use shufflevector instead of shuffle in opt_random.h

On Fri, 11 Oct 2024 at 17:52, Jonathan Wakely wrote: > > On Wed, 9 Oct 2024 at 10:41, Ricardo Jesus wrote: > > > > This patch modifies the implementation of the vectorized Mersenne > > Twister random number generator to use __builtin_shufflevector instead > > of __builtin_shuffle. This makes it (

Re: [PATCH] libstdc++: improve std::atomic compatibility with Clang

On Fri, 11 Oct 2024 at 20:35, Jonathan Wakely wrote: > > On Fri, 11 Oct 2024 at 20:33, Jonathan Wakely wrote: > > > > On Sat, 21 Sept 2024 at 10:43, Giuseppe D'Angelo > > wrote: > > > > > > Hello, > > > > > > The attached patch modifies std::atomic's primary template. The goal is > > > to improv

Re: [PATCH][aarch64][libstdc++] Use shufflevector instead of shuffle in opt_random.h

On Fri, 11 Oct 2024 at 21:00, Jonathan Wakely wrote: > > On Fri, 11 Oct 2024 at 19:52, Christophe Lyon > wrote: > > > > On Fri, 11 Oct 2024 at 17:52, Jonathan Wakely wrote: > > > > > > On Wed, 9 Oct 2024 at 10:41, Ricardo Jesus wrote: > > > > > > > > This patch modifies the implementation of th

[PATCH v4 1/2] libstdc++: Enable memcpy optimizations for distinct integral types [PR93059]

Sigh, the v3 patch had a stray "#pragma GCC" in it somehow, so now here's v4. Unchanged apart from removing that. Testing powerpc64le-linux ... -- >8 -- Currently we only optimize std::copy, std::copy_n etc. to memmove when the source and destination types are the same. This means that we fail t

Re: ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

On Wed, 25 Sep 2024, Lewis Hyatt wrote: > Hello- > > May I please ping this one? Is there something maybe sub-optimal about > how I organized it? I can adjust or break it into two maybe if that's > helpful. Or else, if it's just that #pragma push_macro is not widely > used or cared about... I thi

Re: [PATCH] libcpp: Fix _Pragma("GCC system_header") [PR114436]

On Sat, 23 Mar 2024, Lewis Hyatt wrote: > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436 > > This is a small fix for the issue mentioned in the PR that _Pragma("GCC > system_header") does not work completely. I believe it was always the case > since _Pragma() support was first ad

[PATCH v8] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

Hi, This is the 8th version of the patch. Compared to the 7th version, the major changes are several documentation wording issues raised by Joseph. The 7th version is at: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/664032.html bootstrapped and regress tested on both X86 and aarch64.

ping Re: RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen

Hi - (ping) commit 23c3100e992029994f33eb4a1465570b476c1df4 (HEAD -> master) Author: Frank Ch. Eigler Date: Mon Sep 23 18:03:31 2024 -0400 contrib/test_summary: Add bunsen uploading mode This makes it easy for someone to push gcc dejagnu/autoconf test results to a bunsen [1]

Re: [PATCH] g++.target/i386/pr105953.C: Skip for x32

On Thu, Oct 10, 2024 at 7:16 PM H.J. Lu wrote: > > Since -mabi=ms isn't supported for x32, skip g++.target/i386/pr105953.C > for x32. > > * g++.target/i386/pr105953.C: Skip for x32. > > > -- > H.J. I am checking in this patch. -- H.J.

Re: [PATCH] gcc.target/i386/pr115407.c: Only run for lp64

On Thu, Oct 10, 2024 at 7:34 PM H.J. Lu wrote: > > On Thu, Oct 10, 2024 at 7:13 PM H.J. Lu wrote: > > > > Since -mcmodel=large is valid only for lp64, run pr115407.c only for > > lp64. > > > > * gcc.target/i386/pr115407.c: Only run for lp64. > > > > -- > > H.J. > > This time is the correct patch.

Re: [PATCH] gcc.target/i386: Replace long with long long

On Thu, Oct 10, 2024 at 7:32 PM H.J. Lu wrote: > > On Thu, Oct 10, 2024 at 7:14 PM H.J. Lu wrote: > > > > Since long is 64-bit for x32, replace long with long long for x32. > > > > * gcc.target/i386/bmi2-pr112526.c: Replace long with long long. > > * gcc.target/i386/pr105854.c: Likewise. > > * gc

Re: [PATCH] libstdc++: improve std::atomic compatibility with Clang

On Sat, 21 Sept 2024 at 10:43, Giuseppe D'Angelo wrote: > > Hello, > > The attached patch modifies std::atomic's primary template. The goal is > to improve compatibility with Clang, while also possibly making it more > complaint with the changes introduced by P0883 / C++20. > > Simplifying, std::a

Re: [PATCH] libstdc++: improve std::atomic compatibility with Clang

On Fri, 11 Oct 2024 at 20:33, Jonathan Wakely wrote: > > On Sat, 21 Sept 2024 at 10:43, Giuseppe D'Angelo > wrote: > > > > Hello, > > > > The attached patch modifies std::atomic's primary template. The goal is > > to improve compatibility with Clang, while also possibly making it more > > complai

Re: [patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Good to go. On Fri, Oct 11, 2024, 9:06 AM Thomas Koenig wrote: > Am 11.10.24 um 18:00 schrieb Thomas Koenig: > > Hello world, > > > > the attached patch creates an unsigned "standard" for the > > gfc_option.allow_std field. > > > > One of the main reason why people want UNSIGNED for Fortran is >

Re: [PATCH 2/2] PR target/117048 aarch64: Use more canonical and optimization-friendly representation for XAR instruction

Kyrylo Tkachov writes: >> Kyrylo Tkachov writes: >>> The pattern for the Advanced SIMD XAR instruction isn't very >>> optimization-friendly at the moment. >>> In the testcase from the PR once simlify-rtx has done its work it >>> generates the RTL: >>> (set (reg:V2DI 119 [ _14 ]) >>>(rotate:V2

[PATCH 0/5] Provide better definitions of NULL

Hi, This is just an untested draft. If there's rough agreement that this is wanted, I'll test it, write changelog, etc. The intention of this change is to help improve the common C/C++ language subset, promoting the use of NULL in both languages as the null pointer constant, expanding to nullptr

[PATCH 1/5] gcc/ginclude/stddef.h: Indent nested cpp conditionals

This is in preparation for the following commits. Signed-off-by: Alejandro Colomar --- gcc/ginclude/stddef.h | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/gcc/ginclude/stddef.h b/gcc/ginclude/stddef.h index 349213108ce..f2c4f28673c 100644 --- a/gcc/gi

[PATCH 4/5] Don't define NULL as 0 in C

That was insane. Link: Signed-off-by: Alejandro Colomar --- gcc/testsuite/gcc.c-torture/execute/pr68143_1.c | 2 +- gcc/testsuite/gcc.c-torture/execute/pr70566.c | 2 +- gcc/testsuite/gcc.dg/tm/20100615.c | 2 +- gcc/testsuite/gcc.targe

[PATCH 2/5] gcc/ginclude/stddef.h: Invert conditional

This is in preparation for the following commit. Signed-off-by: Alejandro Colomar --- gcc/ginclude/stddef.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/ginclude/stddef.h b/gcc/ginclude/stddef.h index f2c4f28673c..4d04b0163d5 100644 --- a/gcc/ginclude/stddef.h ++

[PATCH 5/5] libgm2/libm2pim/wrapc.cc: Define NULL as nullptr

For internal C++ code, unconditionally define NULL as nullptr. We already require a C++11 compiler to bootstrap GCC anyway. Link: Signed-off-by: Alejandro Colomar --- libgm2/libm2pim/wrapc.cc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) d

[PATCH 3/5] gcc/ginclude/stddef.h: Define NULL as nullptr if possible

0 is a terrible definition of NULL. If possible, that is, for C++11 or later, define is as nullptr. Link: Signed-off-by: Alejandro Colomar --- gcc/ginclude/stddef.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gcc/ginclude

Re: [PATCH 1/2] libstdc++: Enable memcpy optimizations for distinct integral types [PR93059]

On Fri, 11 Oct 2024 at 07:48, Jonathan Wakely wrote: > > Tested x86_64-linux. > > -- >8 -- > > Currently we only optimize std::copy, std::copy_n etc. to memmove when > the source and destination types are the same. This means that we fail > to optimize copying between distinct 1-byte types, e.g. c

Re: [PATCH][PR113816] AArch64: Use SIMD+GPR for logical vector reductions

On 10/11/24 4:08 AM, Richard Sandiford wrote: Tamar Christina writes: -Original Message- From: Richard Biener Sent: Friday, October 11, 2024 7:52 AM To: Richard Sandiford Cc: Jennifer Schmitz ; gcc-patches@gcc.gnu.org; Richard Earnshaw ; Kyrylo Tkachov ; Tamar Christina Subject: R

Re: [PATCH v1 1/4] Match: Support form 1 for vector signed integer SAT_SUB

On Fri, Oct 11, 2024 at 11:44 AM Li, Pan2 wrote: > > Thanks Richard for reviewing and comments. > > > I wonder since we now can match many different variants of writing > > signed and unsigned > > saturation add and sub whether it makes sense to canonicalize to the > > "cheapest" > > variant when

Re: [PATCH 1/2] PR 117048: simplify-rtx: Extend (x << C1) | (X >> C2) --> ROTATE transformation to vector operands

Kyrylo Tkachov writes: > Hi all, > > In the testcase from patch [2/2] we want to match a vector rotate operation > from > an IOR of left and right shifts by immediate. simplify-rtx has code for just > that but it looks like it's prepared to do handle only scalar operands. > In practice most of t

Re: [PATCH 2/2] PR target/117048 aarch64: Use more canonical and optimization-friendly representation for XAR instruction

Kyrylo Tkachov writes: > The pattern for the Advanced SIMD XAR instruction isn't very > optimization-friendly at the moment. > In the testcase from the PR once simlify-rtx has done its work it > generates the RTL: > (set (reg:V2DI 119 [ _14 ]) > (rotate:V2DI (xor:V2DI (reg:V2DI 114 [ vect__1.1

Re: [PATCH] c: Implement C2Y N3355 - Named Loops [PR117022]

There should definitely be a test that -std=c23 -pedantic-errors gives errors for these constructs (I'd say also test that -std=c23 -pedantic-errors -Wno-c23-c2y-compat doesn't diagnose them, while -std=c2y -Wc23-c2y-compat does). Not yet reviewed the rest of the patch. -- Joseph S. Myers jos

RE: [PATCH v1 1/4] Match: Support form 1 for vector signed integer SAT_SUB

Thanks Richard for reviewing and comments. > I wonder since we now can match many different variants of writing > signed and unsigned > saturation add and sub whether it makes sense to canonicalize to the > "cheapest" > variant when the target doesn't support .SAT_SUB/ADD? I think it is a good

Re: [PATCH 2/2] PR target/117048 aarch64: Use more canonical and optimization-friendly representation for XAR instruction

> On 11 Oct 2024, at 12:36, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov writes: >> The pattern for the Advanced SIMD XAR instruction isn't very >> optimization-friendly at the moment. >> In the testcase from the PR once simlify-r

[PATCH v3 4/5] c++/modules: Check linkage for exported declarations

Updated to use 'unnamed namespace' instead, added some more details to the internal linkage namespace diagnostic. -- >8 -- By [module.interface] p3, if an exported declaration is not within a header unit, it shall not declare a name with internal linkage. Unfortunately we cannot just do this wit

Re: [PATCH 4/4] c++: enable modules by default in c++20

On Wed, Oct 09, 2024 at 07:06:26PM -0400, Patrick Palka wrote: > On Wed, 9 Oct 2024, Jason Merrill wrote: > > > Tested x86_64-pc-linux-gnu, will apply to trunk with the rest of the patch > > series. > > > > -- 8< -- > > > > At this point there doesn't seem to be much reason not to have modules >

Re: pair-fusion: Assume alias conflict if common address reg changes [PR116783]

Alex Coplan writes: > Hi, > > As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into > returning false when a common base register (in this case, x1) was > modified between the mem and the store insn. This lead to wrong code as > the accesses really did alias. > > To avoid this

[PATCH] [RFC] target/117072 - more RTL FMA canonicalization

The following helps the x86 backend by canonicalizing FMAs to have any negation done to one of the commutative multiplication operands be done to a register (and not a memory operand). Likewise to put a register operand first and a memory operand second; swap_commutative_operands_p seems to treat

Re: pair-fusion: Assume alias conflict if common address reg changes [PR116783]

On Fri, 11 Oct 2024, Richard Sandiford wrote: > Alex Coplan writes: > > Hi, > > > > As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into > > returning false when a common base register (in this case, x1) was > > modified between the mem and the store insn. This lead to wrong

[Patch] Fortran: Dead-function removal in error.cc (shrinking by 40%)

I found always error.cc rather confusing but I just realized that we can reduce number of lines in that file by 40% - and remove a lot of (apparent) complexity. The removed code is from the old days, when gfortran handled a lot of diagnostic itself, also because it wanted to show lines with caret

[PATCH] tree-optimization/117080 - Add SLP_TREE_MEMORY_ACCESS_TYPE

It turns out target costing code looks at STMT_VINFO_MEMORY_ACCESS_TYPE to identify operations from (emulated) gathers for example. This doesn't work for SLP loads since we do not set STMT_VINFO_MEMORY_ACCESS_TYPE there as the vectorization strathegy might differ between different stmt uses. It s

Re: [PATCH 1/2] PR 117048: simplify-rtx: Extend (x << C1) | (X >> C2) --> ROTATE transformation to vector operands

> On 11 Oct 2024, at 12:28, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov writes: >> Hi all, >> >> In the testcase from patch [2/2] we want to match a vector rotate operation >> from >> an IOR of left and right shifts by immediate.

[PATCH] c, v2: Implement C2Y N3355 - Named Loops [PR117022]

On Fri, Oct 11, 2024 at 02:19:08PM +, Joseph Myers wrote: > There should definitely be a test that -std=c23 -pedantic-errors gives > errors for these constructs (I'd say also test that -std=c23 > -pedantic-errors -Wno-c23-c2y-compat doesn't diagnose them, while -std=c2y > -Wc23-c2y-compat do

Re: [patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Am 11.10.24 um 18:00 schrieb Thomas Koenig: Hello world, the attached patch creates an unsigned "standard" for the gfc_option.allow_std field. One of the main reason why people want UNSIGNED for Fortran is interfacing for C. This is a preparation for further work on the ISO_C_BINDING constants

Android: Fix build for Android

This is a patch to fix target android 0001-Android-Fix-build-for-Android.patch Description: Binary data

Re: [PATCH v7] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

On Fri, 27 Sep 2024, Qing Zhao wrote: > + if (TREE_CODE (TREE_TYPE (ref)) != ARRAY_TYPE) > + { > + error_at (loc, "the argument must be an array" > +"%<__builtin_counted_by_ref%>"); This diagnostic is missing a space before %<__builtin_cou

RISC-V: Add implication for M extension.

Sending this with a text attachment to see if patchworks accepts a 'text/x-patch' attachment type. Review can still happen on the original thread: https://inbox.sourceware.org/gcc-patches/cafryf0mmb9hs9cng4w8y5n06d+4tfuvgrrrnvuvtsropman...@mail.gmail.com/T/#u Sorry for the technical difficulties

[PATCH v3 1/2] libstdc++: Enable memcpy optimizations for distinct integral types [PR93059]

The __memcpyable_integer specializations for __int128 etc. need the __extension__ keyword to avoid -Wpedantic warnings. [PATCH v2 2/2] is unchanged, so I haven't resent it. -- >8 -- Currently we only optimize std::copy, std::copy_n etc. to memmove when the source and destination types are the sa

Re: RISC-V: Add implication for M extension.

On 10/11/24 09:16, Patrick O'Neill wrote: Sending this with a text attachment to see if patchworks accepts a 'text/x-patch' attachment type. Review can still happen on the original thread: https://inbox.sourceware.org/gcc-patches/cafryf0mmb9hs9cng4w8y5n06d+4tfuvgrrrnvuvtsropman...@mail.gmail.co

Re: [PATCH][aarch64][libstdc++] Use shufflevector instead of shuffle in opt_random.h

On Wed, 9 Oct 2024 at 10:41, Ricardo Jesus wrote: > > This patch modifies the implementation of the vectorized Mersenne > Twister random number generator to use __builtin_shufflevector instead > of __builtin_shuffle. This makes it (almost) compatible with Clang. > > To make the implementation full

[patch, Fortran, RFC] Introduce GFC_STD_UNSIGNED

Hello world, the attached patch creates an unsigned "standard" for the gfc_option.allow_std field. One of the main reason why people want UNSIGNED for Fortran is interfacing for C. This is a preparation for further work on the ISO_C_BINDING constants. That, we do via iso-c-binding.def , whose l

[PING^2] [PATCH] c: Diagnose declarations that are used only in their own initializer [PR115027]

I like to ping this patch. Am Freitag, dem 09.08.2024 um 10:20 +0200 schrieb Martin Uecker: > ok? > > Am Samstag, dem 29.06.2024 um 20:30 +0200 schrieb Martin Uecker: > > Probably not entirely fool-proof when using statement > > expressions in initializers, but should be good enough. > > > >

Re: [PING^2] [PATCH] c: Diagnose declarations that are used only in their own initializer [PR115027]

On Fri, Oct 11, 2024 at 06:35:26PM +0200, Martin Uecker wrote: > > I like to ping this patch. I'm a little bit worried about cases like: int *p; struct S { int *s; }; int *bar (int *s; }; int *baz (void); void foo (void) { struct S a = { bar (&a.s) }; struct S b = { (p = &a.s, baz ()) }; }

Re: [PATCH] libcpp, v2: Add -Wtrailing-whitespace= warning

On Thu, 19 Sep 2024, Jakub Jelinek wrote: > Here is a patch which currently allows blank (' ' '\t') and space (' ' '\t' > '\f' '\v'), cntrl not yet added, not anything non-ASCII, but in theory could > be added later (though, non-ASCII would be just for inside of comments, > say non-breaking space

Re: [PATCH v2] aarch64: Add support for Ampere-1B (-mcpu=ampere1b) CPU

We just noticed that we didn't request to backport this one… OK for backport? On Thu, 30 Nov 2023 at 00:55, Philipp Tomsich wrote: > Applied to master, thanks! > Philipp. > > On Tue, 28 Nov 2023 at 12:57, Richard Sandiford > wrote: > > > > Philipp Tomsich writes: > > > On Tue, 28 Nov 2023 at 1

Re: [PATCH v7] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

Thanks for the comments. Will fix all these issues and send out the 8th version soon. Qing > On Oct 11, 2024, at 13:16, Joseph Myers wrote: > > On Fri, 27 Sep 2024, Qing Zhao wrote: > >> +if (TREE_CODE (TREE_TYPE (ref)) != ARRAY_TYPE) >> + { >> + error_at (loc, "the argument must be

Re: [PATCH][aarch64][libstdc++] Use shufflevector instead of shuffle in opt_random.h

On Fri, 11 Oct 2024 at 19:52, Christophe Lyon wrote: > > On Fri, 11 Oct 2024 at 17:52, Jonathan Wakely wrote: > > > > On Wed, 9 Oct 2024 at 10:41, Ricardo Jesus wrote: > > > > > > This patch modifies the implementation of the vectorized Mersenne > > > Twister random number generator to use __bui

Re: [PATCH v7] c++: Fix overeager Woverloaded-virtual with conversion operators [PR109918]

On 10/11/24 7:02 AM, Simon Martin wrote: Hi Jason, On 11 Oct 2024, at 0:35, Jason Merrill wrote: On 10/7/24 3:35 PM, Simon Martin wrote: On 7 Oct 2024, at 18:58, Jason Merrill wrote: On 10/7/24 11:27 AM, Simon Martin wrote: /* Now give a warning for all base functions without over

[PATCH 1/4] RISC-V: Add testcases for form 2 of vector signed SAT_SUB

From: Pan Li Form 2: #define DEF_VEC_SAT_S_SUB_FMT_2(T, UT, MIN, MAX) \ void __attribute__((noinline)) \ vec_sat_s_sub_##T##_fmt_2 (T *out, T *op_1, T *op_2, unsigned limit) \ {

[PATCH 2/4] Match: Support form 3 for vector signed integer SAT_SUB

From: Pan Li This patch would like to support the form 3 of the vector signed integer SAT_SUB. Aka below example: Form 3: #define DEF_VEC_SAT_S_SUB_FMT_3(T, UT, MIN, MAX) \ void __attribute__((noinline)) \ vec_sat_s_sub_##T##_fmt_3

[PATCH 4/4] RISC-V: Add testcases for form 4 of vector signed SAT_SUB

From: Pan Li Form 4: #define DEF_VEC_SAT_S_SUB_FMT_4(T, UT, MIN, MAX) \ void __attribute__((noinline)) \ vec_sat_s_sub_##T##_fmt_4 (T *out, T *op_1, T *op_2, unsigned limit) \ {

[PATCH 3/4] RISC-V: Add testcases for form 3 of vector signed SAT_SUB

From: Pan Li Form 3: #define DEF_VEC_SAT_S_SUB_FMT_3(T, UT, MIN, MAX) \ void __attribute__((noinline)) \ vec_sat_s_sub_##T##_fmt_3 (T *out, T *op_1, T *op_2, unsigned limit) \ {

  1   2   >