[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) \ {

[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 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 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) \ {

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

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

On 10/11/24 8:19 AM, Jakub Jelinek wrote: 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

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

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

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

[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] 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/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/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

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

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

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

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]

[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: [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] 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] 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][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

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][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 (

[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 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 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] 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: [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, 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, > -

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

Android: Fix build for Android

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

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

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

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

[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

[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

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

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

On Fri, Oct 11, 2024 at 02:55:38PM GMT, Joseph Myers wrote: > On Fri, 11 Oct 2024, Alejandro Colomar wrote: > > > That was insane. > > > > Link: > > Signed-off-by: Alejandro Colomar > > --- > > gcc/testsuite/gcc.c-torture/execute/pr68143_1.c | 2 +- >

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

Hi Joseph, On Fri, Oct 11, 2024 at 02:59:50PM GMT, Joseph Myers wrote: > On Fri, 11 Oct 2024, Alejandro Colomar wrote: > > > That was insane. > > Also please avoid such pejorative language in commit messages. The > libiberty code here is 30-40 years (or more) old; the definition would > have

[PATCH v2 2/2] libstdc++: Enable memset optimizations for distinct character types [PR93059]

This adds __are_same to the enable_if condition, to ensure that the optimized overload can still be selected for std::byte (because that's no longer done via a __memcpyable_integer specialization). Tested x86_64-linux. -- >8 -- Currently we only optimize std::fill to memset when the source and d

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

On Fri, 11 Oct 2024, Alejandro Colomar wrote: > That was insane. Also please avoid such pejorative language in commit messages. The libiberty code here is 30-40 years (or more) old; the definition would have made a lot more sense in a pre-standard C context when it was written. -- Joseph S.

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

This removes the __memcpyable_integer specialization (for the reasons given earlier, and the commit msg below). 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

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

> On 11 Oct 2024, at 13:18, Kyrylo Tkachov wrote: > > Hi Jennifer, > >> On 11 Oct 2024, at 10:00, Jennifer Schmitz wrote: >> >> >> >>> On 8 Oct 2024, at 10:44, Richard Biener wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> >>> On Thu, 3 Oct 2024, Jennife

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

> Am 11.10.2024 um 16:43 schrieb Jennifer Schmitz : > >  > >> 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: Frida

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

On Fri, 11 Oct 2024, Alejandro Colomar wrote: > 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/gc

[committed] libstdc++: Fix localized %c formatting for [PR117085]

Tested x86_64-linux. Pushed to trunk. -- >8 -- When formatting a time point with %c we call std::vformat_to using the formatting locale's D_T_FMT string, but we weren't adding the L option to the format string. This meant we always interpreted D_T_FMT in the C locale, instead of using the formatt

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

[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

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

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: 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][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

[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 v3 1/5] openmp: Refactor handling of iterators

On Fri, Oct 04, 2024 at 03:54:53PM +0100, Kwok Cheung Yeung wrote: > +/* Returns a tree expression containing the total iteration count of the > + iterator clause decl T. */ s/iterator/OpenMP iterator/ > + > +static tree > +compute_iterator_count (tree t, gimple_seq *pre_p) s/_iterator/_omp_i

[PATCH v3 3/5] c++/modules: Support unnamed namespaces in header units

Added the rationale comment for the 'make_namespace_finish' changes, changed commit message to mention 'unnamed' rather than 'anonymous' namespaces. -- >8 -- A header unit may contain unnamed namespaces, and those declarations are exported (as with any declaration in a header unit). This patch e

[PATCH v3 5/5] c++/modules: Validate external linkage definitions in header units [PR116401]

Added a comment to grokfndecl about marking deduction guides as inline. An alternative would be to instead specially handle deduction guides in check_module_decl_linkage; would that maybe be preferable? -- >8 -- [module.import] p6 says "A header unit shall not contain a definition of a non-inlin

[PATCH v3 2/5] c++/modules: Ignore TU-local entities where necessary

This version rewords all "ignored exposures" language. I haven't fixed up the issue with DECL_TEMPLATE_INSTANTIATIONS for this patch. I'll try to get to that as a separate patch if I find the time, but it's not 100% needed here I don't think. It seems the discussion around PR115126 RE: the libgc

[PATCH v3 1/5] c++/modules: Detect exposures of TU-local entities

On Sat, Sep 28, 2024 at 1:56 AM Jason Merrill wrote: > I agree that LAMBDA_TYPE_EXTRA_SCOPE should do the trick; a lambda is > TU-local if it has no mangling scope. I'd prefer to pursue fixing holes > in LAMBDA_TYPE_EXTRA_SCOPE as needed to make it work, starting with the > patch above. > > Maybe

[PATCH v3 0/5] c++/modules: Implement P1815 "Translation-unit-local entities"

This patch series implements most of the changes made by P1815. It also cleans up a few bugs found along the way that impacted tests I wrote. The whole patch series was bootstrapped on x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu with no regressions. A range-diff against v2 is attached; the

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

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_internal/1 Followed shortly by: vmv.s.x v3,a4 # 261

[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

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

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: 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] [RFC] target/117072 - more RTL FMA canonicalization

On Fri, Oct 11, 2024 at 8:22 PM Richard Biener wrote: > > 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 m

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

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

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

[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

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

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

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

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

Hi Jennifer, > On 11 Oct 2024, at 10:00, Jennifer Schmitz wrote: > > > >> 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 B

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

Jennifer Schmitz writes: > 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 t

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

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 overriders, as they are hidden.

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

  1   2   >