Re: [PATCH v5] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]

../../libcpp/directives.cc: In function 'void do_pragma_once(cpp_reader*)': ../../libcpp/directives.cc:2078:20: error: unknown conversion type character '<' in format [-Werror=format=] 2078 | "%<#pragma once%> in main file"); |^ ../../libcpp/directives.c

[r15-4186 Regression] FAIL: gcc.dg/pr67089-6.c scan-tree-dump-times widening_mul "SUB_OVERFLOW" 9 on Linux/x86_64

On Linux/x86_64, 0883c88664d48463dfc79335dccaf15a69230952 is the first bad commit commit 0883c88664d48463dfc79335dccaf15a69230952 Author: Artemiy Volkov Date: Tue Oct 8 17:51:08 2024 -0600 tree-optimization/116024 - simplify C1-X cmp C2 for UB-on-overflow types caused FAIL: gcc.dg/pr6708

Re: [RFC/RFA] [PATCH v4 01/12] Implement internal functions for efficient CRC computation

On 10/8/24 4:52 AM, Mariam Arutunian wrote: On Sun, Sep 29, 2024 at 9:08 PM Jeff Law > wrote: On 9/13/24 5:05 AM, Mariam Arutunian wrote: > Add two new internal functions (IFN_CRC, IFN_CRC_REV), to provide faster > CRC generation. > On

[PATCH v1 2/2] RISC-V: Add testcases for form 2 of scalar signed SAT_TRUNC

From: Pan Li Form 2: #define DEF_SAT_S_TRUNC_FMT_2(NT, WT, NT_MIN, NT_MAX) \ NT __attribute__((noinline)) \ sat_s_trunc_##WT##_to_##NT##_fmt_2 (WT x) \ { \ NT trunc = (NT)x;

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

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)) \ sat_s_trunc_##WT##_to_##NT##_fmt_2 (WT x)

[PATCH v3 2/2] Adjust testcase after relax O2 vectorization.

Update in V3. >The testcase looks bogus: > > b[i+k] = b[i+k-5] + 2; > >accesses b[-3], can you instead adjust the inner loop to start with k == 4? Changed, also adjust b[100] to b[200] to avoid array out of bound. >Please remove this testcase - even with fully masking we'd need alias >versi

[PATCH v3 1/2] Enable vectorization for unknown tripcount in very cheap cost model but disable epilog vectorization.

>We'd also need to update the documentation: >... The @samp{very-cheap} model only >allows vectorization if the vector code would entirely replace the >scalar code that is being vectorized. For example, if each iteration >of a vectorized loop would only be able to handle exactly four iterations >

[PATCH] Don't lower vpcmpu to pcmpgt since the latter is for signed comparison.

r15-1737-gb06a108f0fbffe lower AVX512 kmask comparison to AVX2 ones, but wrong lowered unsigned comparison to signed ones, for unsigned comparison, only EQ/NEQ can be lowered. The commit fix that. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ready push to trunk. gcc/ChangeLog:

Re: [PATCH 3/3] aarch64: libgcc: Add -Werror support

On Tue, Oct 8, 2024 at 6:25 AM Richard Sandiford wrote: > > Christophe Lyon writes: > > When --enable-werror is enabled when running the top-level configure, > > it passes --enable-werror-always to subdirs. Some of them, like > > libgcc, ignore it. > > > > This patch adds support for it, enabled

Re: [PATCH v4 4/4] tree-optimization/116024 - simplify some cases of X +- C1 cmp C2

On 9/30/24 2:04 AM, Artemiy Volkov wrote: Whenever C1 and C2 are integer constants, X is of a wrapping type, and cmp is a relational operator, the expression X +- C1 cmp C2 can be simplified in the following cases: (a) If cmp is <= and C2 -+ C1 == +INF(1), we can transform the initial compari

Re: [PATCH v4 3/4] tree-optimization/116024 - simplify C1-X cmp C2 for wrapping signed types

On 9/30/24 2:04 AM, Artemiy Volkov wrote: Implement a match.pd transformation inverting the sign of X in C1 - X cmp C2, where C1 and C2 are integer constants and X is of a wrapping signed type, by observing that: (a) If cmp is == or !=, simply move X and C2 to opposite sides of the comparison

Re: [PATCH v4 2/4] tree-optimization/116024 - simplify C1-X cmp C2 for unsigned types

On 9/30/24 2:04 AM, Artemiy Volkov wrote: Implement a match.pd transformation inverting the sign of X in C1 - X cmp C2, where C1 and C2 are integer constants and X is of an unsigned type, by observing that: (a) If cmp is == or !=, simply move X and C2 to opposite sides of the comparison to ar

Re: [PATCH v4 1/4] tree-optimization/116024 - simplify C1-X cmp C2 for UB-on-overflow types

On 9/30/24 2:04 AM, Artemiy Volkov wrote: Implement a match.pd pattern for C1 - X cmp C2, where C1 and C2 are integer constants and X is of a UB-on-overflow type. The pattern is simplified to X rcmp C1 - C2 by moving X and C2 to the other side of the comparison (with opposite signs). If C1 -

Re: [PATCH] RISC-V: Enable builtin __riscv_mul with Zmmul extension.

On 10/8/24 12:25 AM, Tsung Chun Lin wrote: From d5b254e19d1f37fe27c7e98a0160e5c22446cfea Mon Sep 17 00:00:00 2001 From: Jim Lin Date: Tue, 8 Oct 2024 13:14:32 +0800 Subject: [PATCH] RISC-V: Enable builtin __riscv_mul with Zmmul extension. gcc/ChangeLog: * config/riscv/riscv-c.cc:

Re: [PATCH v5] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]

On Tuesday, October 8th, 2024 at 11:21 AM, Marek Polacek wrote: > > > On Mon, Oct 07, 2024 at 11:16:20PM +, Ken Matsui wrote: > > > On Monday, October 7th, 2024 at 4:41 PM, Marek Polacek pola...@redhat.com > > wrote: > > > > > On Sat, Jun 15, 2024 at 10:30:35PM -0700, Ken Matsui wrote

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

On 10/7/24 11:33 PM, Tsung Chun Lin wrote: That M implies Zmmul. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: M implies Zmmul. THanks. I've pushed this to the trunk. jeff ps. Quite a discussion on this topic in the zmmul public discussion from a couple years ago. But

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

> -Original Message- > From: Richard Biener > Sent: Wednesday, October 2, 2024 1:50 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH]middle-end: support SLP early break > > On Tue, 1 Oct 2024, Tamar Christina wrote: > > > Hi all, >

Re: [PATCH] Add fancy pointer support in std::map/set

On Tue, 8 Oct 2024 at 22:50, Jonathan Wakely wrote: > > > On Thu, 1 Aug 2024 at 18:28, François Dumont wrote: > >> Hi >> >> Here is a proposal to add fancy pointer support in std::_Rb_tree >> container. >> >> As you'll see there are still several usages of >> pointer_traits<>::pointer_to. The on

Re: [PATCH] Add fancy pointer support in std::map/set

On Tue, 8 Oct 2024 at 22:50, Jonathan Wakely wrote: > > > On Thu, 1 Aug 2024 at 18:28, François Dumont wrote: > >> Hi >> >> Here is a proposal to add fancy pointer support in std::_Rb_tree >> container. >> >> As you'll see there are still several usages of >> pointer_traits<>::pointer_to. The on

Re: [PATCH] Add fancy pointer support in std::map/set

On Thu, 1 Aug 2024 at 18:28, François Dumont wrote: > Hi > > Here is a proposal to add fancy pointer support in std::_Rb_tree container. > > As you'll see there are still several usages of > pointer_traits<>::pointer_to. The ones in _M_header_ptr() are > unavoidable. Yes, those are necessary.

Re: [PATCH v2] RISC-V: Improve vsetvl vconfig alignment

On 10/2/24 6:27 AM, Dusan Stojkovic wrote: This patch is a new version of: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662745.html > Can you elaborate a bit on that?  Rearranging the CFG shouldn't matter >

Re: [PATCH] c: Speed up compilation of large char array initializers when not using #embed

On Sat, 3 Aug 2024, Jakub Jelinek wrote: > * c-c++-common/init-1.c: New test. I think there should also be tests of initializing signed char (and plain char) arrays; I don't see any such tests here. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] libcpp, c, middle-end: Optimize initializers using #embed in C

On Thu, 11 Jul 2024, Jakub Jelinek wrote: > With the CPP_NUMBERs around it, I believe in the C FE the only places which > need handling of the CPP_EMBED token are initializer parsing (that is the > only one which adds actual optimizations for it), comma expressions (I > believe nothing really care

[PATCH v3 2/2] Enable LRA for ia64

From: René Rebe This was tested by bootstrapping GCC natively on ia64-t2-linux-gnu and running the testsuite (based on 236116068151bbc72aaaf53d0f223fe06f7e3bac): https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html For comparison, the same with just 236116068151bbc72aaaf53d0f22

[PATCH v3 1/2] Remove ia64*-*-linux from the list of obsolete targets

From: René Rebe The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to support this for some years to come. gcc/ * config.gcc: Only list ia64*-*-(hpux|vms|elf) in the list of obsoleted targets. contrib/ * config-list.mk (LIST): no --enable-obsolete fo

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

[CC -= Jens] Hi Joseph, On Tue, Oct 08, 2024 at 03:13:19PM GMT, Joseph Myers wrote: > On Tue, 8 Oct 2024, Alejandro Colomar wrote: > > > > I have plenty of concerns with > > > both the wording and incompatibility of various changes suggested there > > > related to what's allowed as a sizeof op

[PATCH v3 0/2] ia64: enable LRA and un-obsolete ia64*-*-linux

With stage 3 of GCC 15 approaching, to save me some time by finally dropping the non-LRA testcase from my cross builds of GCC and Linux and as I had the time, I updated the patch set from René with the requested changes and rebased it to 0ad2c76bea20dbeac753f10df6f9f86d142348d4. Patch 1/2: Remove

Re: [PATCH v2 2/2] Enable LRA for ia64

On 08.10.24 21:08, Jonathan Wakely wrote: On Tue, 8 Oct 2024 at 20:02, Frank Scheiner wrote: On 08.10.24 20:54, Jonathan Wakely wrote: On Tue, 8 Oct 2024 at 18:43, Frank Scheiner wrote: This was tested by bootstrapping GCC natively on ia64-t2-linux-gnu and running the testsuite (based on

Re: [PATCH v2 2/2] Enable LRA for ia64

On Tue, 8 Oct 2024 at 20:02, Frank Scheiner wrote: > > > > On 08.10.24 20:54, Jonathan Wakely wrote: > > On Tue, 8 Oct 2024 at 18:43, Frank Scheiner wrote: > >> > >> This was tested by bootstrapping GCC natively on ia64-t2-linux-gnu and > >> running the testsuite (based on > >> 236116068151bbc72a

Re: [PATCH v2 2/2] Enable LRA for ia64

On 08.10.24 20:54, Jonathan Wakely wrote: On Tue, 8 Oct 2024 at 18:43, Frank Scheiner wrote: This was tested by bootstrapping GCC natively on ia64-t2-linux-gnu and running the testsuite (based on 236116068151bbc72aaaf53d0f223fe06f7e3bac): https://gcc.gnu.org/pipermail/gcc-testresults/2024-J

Re: [PATCH v2 2/2] Enable LRA for ia64

On Tue, 8 Oct 2024 at 18:43, Frank Scheiner wrote: > > This was tested by bootstrapping GCC natively on ia64-t2-linux-gnu and > running the testsuite (based on > 236116068151bbc72aaaf53d0f223fe06f7e3bac): > > https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > For comparison, t

Re: [PATCH v2] libstdc++: Workaround glibc headers on ia64-linux

On Thu, 3 Oct 2024 at 20:59, Frank Scheiner wrote: > > We see: > > ``` > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) > FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) > ``` > > ...on ia64-lin

[wwwdocs] projects/gomp: Update for TR13; gcc-15/changes.html link to routine doc

Update and sync with https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Implementation-Status.html Current page: https://gcc.gnu.org/projects/gomp/ (and https://gcc.gnu.org/gcc-15/changes.html ) Comments before I apply it? (Comments to the libgomp.texi are also welcome.) Thanks, Tobias projects

Re: [PATCH v2] RISC-V: Improve vsetvl vconfig alignment

On 10/2/24 6:27 AM, Dusan Stojkovic wrote: This patch is a new version of: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662745.html > Can you elaborate a bit on that?  Rearranging the CFG shouldn't matter >

Re: [PATCH v1 4/4] aarch64: encapsulate note.gnu.property emission into a class

Matthieu Longo writes: > gcc/ChangeLog: > > * config.gcc: Add aarch64-dwarf-metadata.o to extra_objs. > * config/aarch64/aarch64-dwarf-metadata.h (class > section_note_gnu_property): > Encapsulate GNU properties code into a class. > * config/aarch64/aarch64.cc > (GNU_PROPERTY_

Re: [PATCH v1 3/4] aarch64: improve assembly debug comments for build attributes

Matthieu Longo writes: > The previous implementation to emit build attributes did not support > string values (asciz) in aeabi_subsection, and was not emitting values > associated to tags in the assembly comments. > > This new approach provides a more user-friendly interface relying on > typing, a

[PATCH v2 2/2] Enable LRA for ia64

This was tested by bootstrapping GCC natively on ia64-t2-linux-gnu and running the testsuite (based on 236116068151bbc72aaaf53d0f223fe06f7e3bac): https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html For comparison, the same with just 236116068151bbc72aaaf53d0f223fe06f7e3bac: http

Re: [PATCH v1 2/4] aarch64: add minimal support for GCS build attributes

Since this is an RFC, it would probably be more helpful to get review comments about the design or the adherence to the spec. I'll need to look into things a bit more for that, though, so I'm afraid the below is more implementation trivia. Matthieu Longo writes: > [...] > diff --git a/gcc/config

[PATCH v2 1/2] Remove ia64*-*-linux from the list of obsolete targets

The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to support this for some years to come. contrib/ * config-list.mk (LIST): no --enable-obsolete for ia64-linux. gcc/ * config.gcc: Only list ia64*-*-(hpux|vms|elf) in the list of obsoleted targets. Sign

[PATCH v2 0/2] ia64: enable LRA and un-obsolete ia64*-*-linux

With stage 3 of GCC 15 approaching, to save me some time by finally dropping the non-LRA testcase from my cross builds of GCC and Linux and as I had the time, I updated the patch set from René with the requested changes and rebased it to 0ad2c76bea20dbeac753f10df6f9f86d142348d4. Patch 1/2: Remove

Re: [PATCH v1 1/4] aarch64: add debug comments to feature properties in .note.gnu.property

Sorry for the slow review. Matthieu Longo writes: > GNU properties are emitted to provide some information about the features > used in the generated code like PAC, BTI, or GCS. However, no debug > comment are emitted in the generated assembly even if -dA is provided. > This makes understanding t

Re: [PATCH v4] RISC-V: Implement TARGET_CAN_INLINE_P

On 10/3/24 9:30 AM, Yangyu Chen wrote: Currently, we lack support for TARGET_CAN_INLINE_P on the RISC-V ISA. As a result, certain functions cannot be optimized with inlining when specific options, such as __attribute__((target("arch=+v"))) . This can lead to potential performance issues when b

Re: [PATCH v2] RISC-V: Optimize branches with shifted immediate operands

On 9/29/24 11:30 PM, Jovan Vukic wrote: Based on the feedback I received, the patch now uses a custom code iterator instead of relying on match_operator. Since both operands (2 and 3) have trailing zeros, an additional check was introduced to verify if they remain SMALL_OPERANDs after shiftin

Re: [PATCH 2/8] aarch64: Add new +fcma flag

Andrew Carlotti writes: > This includes +fcma as a dependency of +sve, and means that we can > finally support fcma intrinsics on a64fx. > > Also add fcma to the Features list in several cpunative testcases that > incorrectly included sve without fcma. > > gcc/ChangeLog: > > * config/aarch64

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

Hello everybody, can you please leave me out of this ever spinning discussion? The discussion in Minneapolis has fulfilled my needs on this for the next 10 years at least. I consider forcing people to opt out of mailings as being quite rude. Thanks Jₑₙₛ -- :: ICube

Re: [PATCH 1/8] aarch64: Use PAUTH instead of V8_3A in some places

Andrew Carlotti writes: > gcc/ChangeLog: > > * config/aarch64/aarch64.cc > (aarch64_expand_epilogue): Use TARGET_PAUTH. > * config/aarch64/aarch64.md: Update comment. > > > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc > index > e7bb3278a27eca44c46af

Re: Ping: [PATCH] gcc/doc: adjust __builtin_choose_expr() description

On 10/8/24 09:35, Jan Beulich wrote: On 08.10.2024 17:30, Sandra Loosemore wrote: [snip] Hmmm, looking at the complete documentation for this built-in, and the code, I think I'd go a little farther with fixing up the docs. Since requiring the first operand to be a constant is also different be

Re: Ping: [PATCH] gcc/doc: adjust __builtin_choose_expr() description

On 08.10.2024 17:30, Sandra Loosemore wrote: > On 10/8/24 08:12, Jan Beulich wrote: >> On 19.06.2024 16:01, Jan Beulich wrote: >>> Present wording has misled people to believe the ?: operator would be >>> evaluating all three of the involved expressions. >>> >>> gcc/ >>> >>> * doc/extend.texi:

Re: Ping: [PATCH] gcc/doc: adjust __builtin_choose_expr() description

On 10/8/24 08:12, Jan Beulich wrote: On 19.06.2024 16:01, Jan Beulich wrote: Present wording has misled people to believe the ?: operator would be evaluating all three of the involved expressions. gcc/ * doc/extend.texi: Clarify __builtin_choose_expr() similarity to the ?: oper

Re: [PATCH v5] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]

On Mon, Oct 07, 2024 at 11:16:20PM +, Ken Matsui wrote: > On Monday, October 7th, 2024 at 4:41 PM, Marek Polacek > wrote: > > > > > > > On Sat, Jun 15, 2024 at 10:30:35PM -0700, Ken Matsui wrote: > > > > > This patch adds a warning switch for "#pragma once in main file". The > > > warning op

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

Joseph wrote: > Length of strings is simply array length of a > sub-array that doesn't include the terminating null character (a case of > the sub-object issue of exactly what object is relevant in what context, > not anything to do with the term "length"). Exactly! This is what eventually persuad

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

On Tue, 8 Oct 2024, Alejandro Colomar wrote: > > I have plenty of concerns with > > both the wording and incompatibility of various changes suggested there > > related to what's allowed as a sizeof operand and associated semantics but > > I don't think there were any concerns in that discussion

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

> ​Because I don't like the paper that has been voted into the standard. > I kind of presented that paper against my will. I wish GCC merged the > feature with a different name, and forced the standard to reconsider > what they merged, which I consider to be a security problem. > > Alternatively,

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

Hi Joseph, On Tue, Oct 08, 2024 at 02:04:12PM GMT, Joseph Myers wrote: > On Tue, 8 Oct 2024, Alejandro Colomar wrote: > > > If you wish to wait for Graz to make sure there's no incompatibility > > with ISO, that's another possibility. > > The name could be changed in GCC after Graz (while in >

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

On Tue, Oct 08, 2024 at 03:40:53PM GMT, Jakub Jelinek wrote: > On Tue, Oct 08, 2024 at 03:28:29PM +0200, Alejandro Colomar wrote: > > On Tue, Oct 08, 2024 at 01:19:06PM GMT, Joseph Myers wrote: > > > On Tue, 8 Oct 2024, Alejandro Colomar wrote: > > > > > > > On Mon, Oct 07, 2024 at 05:35:16PM GMT,

Re: [PATCH] libgcc: Use inline variable instead of function-local static

On Tue, 8 Oct 2024 at 13:59, Michael Matz wrote: > > Hello, > > On Tue, 8 Oct 2024, Jonathan Wakely wrote: > > > We originally had global static variables, which means a different > > variable per TU. That causes ODR violations which were silently > > ignored until we try to use them in modules, w

Re: [PATCH v3 1/2] aarch64: Add SVE2 faminmax intrinsics

Saurabh Jha writes: > Thanks for the review. Wanted to clarify your comment: > > On 10/8/2024 11:51 AM, Richard Sandiford wrote: >> writes: >>> diff --git a/gcc/testsuite/gcc.target/aarch64/sve2/acle/asm/amax_f16.c >>> b/gcc/testsuite/gcc.target/aarch64/sve2/acle/asm/amax_f16.c >>> new file mode

Ping: [PATCH] gcc/doc: adjust __builtin_choose_expr() description

On 19.06.2024 16:01, Jan Beulich wrote: > Present wording has misled people to believe the ?: operator would be > evaluating all three of the involved expressions. > > gcc/ > > * doc/extend.texi: Clarify __builtin_choose_expr() similarity to > the ?: operator. Anyone? I don't think I

[Patch] Fortran/OpenMP: Fix __builtin_omp_is_initial_device

Patches gfc_conv_procedure_call (+ called functions). Found via OpenMP_VV which uses rather pointlessly 'if (omp_is_initial_device() .eqv. .true.)' – instead of using 'if (omp_…())'. This failed with an ICE as the middle end did not like 'if ( == )' comparisons. The initial idea was to crea

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

On Tue, 8 Oct 2024, Alejandro Colomar wrote: > If you wish to wait for Graz to make sure there's no incompatibility > with ISO, that's another possibility. The name could be changed in GCC after Graz (while in regression-fixes-only mode for GCC 15) if WG14 changes the name in Graz. It wouldn't

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

On Tue, Oct 08, 2024 at 03:28:29PM +0200, Alejandro Colomar wrote: > On Tue, Oct 08, 2024 at 01:19:06PM GMT, Joseph Myers wrote: > > On Tue, 8 Oct 2024, Alejandro Colomar wrote: > > > > > On Mon, Oct 07, 2024 at 05:35:16PM GMT, Joseph Myers wrote: > > > > Patches 1, 2 and 3 are logically nothing t

Re: [PATCH] aarch64: Expand CTZ to RBIT + CLZ for SVE [PR109498]

Soumya AR writes: >> On 1 Oct 2024, at 6:17 PM, Richard Sandiford >> wrote: >> >> External email: Use caution opening links or attachments >> >> >> Soumya AR writes: >>> Currently, we vectorize CTZ for SVE by using the following operation: >>> .CTZ (X) = (PREC - 1) - .CLZ (X & -X) >>> >>> Inste

[PATCH] tree-optimization/116575 - handle SLP of permuted masked loads

The following handles SLP discovery of permuted masked loads which was prohibited (because wrongly handled) for PR114375. In particular with single-lane SLP at the moment all masked group loads appear permuted and we fail to use masked load lanes as well. The following addresses parts of the issu

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

Hi Joseph, On Tue, Oct 08, 2024 at 01:19:06PM GMT, Joseph Myers wrote: > On Tue, 8 Oct 2024, Alejandro Colomar wrote: > > > On Mon, Oct 07, 2024 at 05:35:16PM GMT, Joseph Myers wrote: > > > Patches 1, 2 and 3 are logically nothing to do with this feature. I'll > > > wait for them to be reviewed

[PATCH] Fix memory leak in vect_cse_slp_nodes

The following avoids copying scalar stmts again for the re-lookup of the slot to replace the NULL guard with node. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. * tree-vect-slp.cc (vect_cse_slp_nodes): Fix memory leak. --- gcc/tree-vect-slp.cc | 2 +- 1 file ch

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

On Tue, 8 Oct 2024, Alejandro Colomar wrote: > How about adding the __lower__ version now as a GNU extension with > compatible semantics, and when it's closer to an ISO C2y release add the > _Upper one? No, we don't need two names. Just _Lengthof suffices. If semantics change in some way durin

Re: [PATCH v13 0/4] c: Add __lengthof__ operator

On Tue, 8 Oct 2024, Alejandro Colomar wrote: > On Mon, Oct 07, 2024 at 05:35:16PM GMT, Joseph Myers wrote: > > Patches 1, 2 and 3 are logically nothing to do with this feature. I'll > > wait for them to be reviewed so that we only have a single-patch series, > > before doing final review of the

Re: [PATCH] libgcc: Use inline variable instead of function-local static

Hello, On Tue, 8 Oct 2024, Jonathan Wakely wrote: > We originally had global static variables, which means a different > variable per TU. That causes ODR violations which were silently > ignored until we try to use them in modules, where they're diagnosed. > So we need to replace them. Aren't th

Re: [PATCH 3/3] aarch64: libgcc: Add -Werror support

On Tue, 8 Oct 2024 at 12:24, Richard Sandiford wrote: > > Christophe Lyon writes: > > When --enable-werror is enabled when running the top-level configure, > > it passes --enable-werror-always to subdirs. Some of them, like > > libgcc, ignore it. > > > > This patch adds support for it, enabled o

Re: [PATCH v3 1/2] aarch64: Add SVE2 faminmax intrinsics

Thanks for the review. Wanted to clarify your comment: On 10/8/2024 11:51 AM, Richard Sandiford wrote: writes: diff --git a/gcc/testsuite/gcc.target/aarch64/sve2/acle/asm/amax_f16.c b/gcc/testsuite/gcc.target/aarch64/sve2/acle/asm/amax_f16.c new file mode 100644 index 000..de4a6f8efaa

Re: [Fortran, Patch, PR51815, v3] Fix parsing of substring refs in coarrays.

Hi Harald, I agree that the gfc_match_array_ref() is not needed for error recovery or helps anyhow. I therefore removed it. I left the new error message in, because in the case that c = x(:)(2:5) is in a subroutine, like in pr102532.f90, then I get no error. Neither without return MATCH_ERROR nor

Re: [PATCH v1 4/4] RISC-V: Add testcases for form 1 of scalar signed SAT_TRUNC

LGTM 於 2024年10月8日 週二 16:36 寫道： > From: Pan Li > > Form 1: > #define DEF_SAT_S_TRUNC_FMT_1(WT, NT, NT_MIN, NT_MAX) \ > NT __attribute__((noinline)) \ > sat_s_trunc_##WT##_to_##NT##_fmt_1 (WT x) \ > {

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

LGTM 於 2024年10月8日 週二 16:33 寫道： > From: Pan Li > > This patch would like to implement the sstrunc for scalar signed > integer. > > Form 1: > #define DEF_SAT_S_TRUNC_FMT_1(WT, NT, NT_MIN, NT_MAX) \ > NT __attribute__((noinline)) \ > sat_s_trunc_##WT##_to_##NT##_fmt_

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

Thanks richard for comments. > Use HOST_WIDE_INT_1U instead of 1ull > OK with that change. Got it, will commit it with this change if no surprise from test. Pan -Original Message- From: Richard Biener Sent: Tuesday, October 8, 2024 5:07 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; ta

[PATCH] tree-optimization/116974 - Handle single-lane SLP for OMP scan store

The following massages the GIMPLE matching way of handling scan stores to work with single-lane SLP. I do not fully understand all the cases that can happen and the stmt matching at vectorizable_store time is less than ideal - but the following gets me all the testcases to pass with and without fo

Re: [PATCH v3 2/2] aarch64: Add codegen support for SVE2 faminmax

writes: > The AArch64 FEAT_FAMINMAX extension introduces instructions for > computing the floating point absolute maximum and minimum of the > two vectors element-wise. > > This patch adds code generation for famax and famin in terms of existing > unspecs. With this patch: > 1. famax can be expres

Re: [RFC/RFA] [PATCH v4 01/12] Implement internal functions for efficient CRC computation

On Sun, Sep 29, 2024 at 9:08 PM Jeff Law wrote: > > > On 9/13/24 5:05 AM, Mariam Arutunian wrote: > > Add two new internal functions (IFN_CRC, IFN_CRC_REV), to provide faster > > CRC generation. > > One performs bit-forward and the other bit-reversed CRC computation. > > If CRC optabs are support

Re: [PATCH v3 1/2] aarch64: Add SVE2 faminmax intrinsics

writes: > diff --git a/gcc/testsuite/gcc.target/aarch64/sve2/acle/asm/amax_f16.c > b/gcc/testsuite/gcc.target/aarch64/sve2/acle/asm/amax_f16.c > new file mode 100644 > index 000..de4a6f8efaa > --- /dev/null > +++ b/gcc/testsuite/gcc.target/aarch64/sve2/acle/asm/amax_f16.c > @@ -0,0 +1,312

Re: [PING] [PATCH] i386: Implement Thread Local Storage on Windows

> Sorry for not being fast enough to rewrite the patch on my end to integrate > your changes (I'm maintaining this patch for both gcc 14 and master at the > same time, which is a little complicated), but I appreciate the help :) How > did you figure out the issue so quickly? By comparing what happ

Re: [PATCH] libgcc: Use inline variable instead of function-local static

On Tue, Oct 08, 2024 at 11:32:16AM +0100, Jonathan Wakely wrote: > But that's because foo() is declared static, which we can't do because > of C++ modules. That was the original problem Nathaniel was fixing. > > If you remove the 'static' from foo() then both z and _ZZ3foovE1v use > @gnu_unique_ob

Re: [PATCH] libgcc: Use inline variable instead of function-local static

On Tue, 8 Oct 2024 at 11:11, Jakub Jelinek wrote: > > On Tue, Oct 08, 2024 at 10:57:06AM +0100, Jonathan Wakely wrote: > > Whoops, yes of course. Raising the topic of __cxa_guard_acquire was my > > fault, and doesn't apply here, sorry. > > > > But we still want to get rid of the STB_GNU_UNIQUE bin

Re: [PATCH 3/3] aarch64: libgcc: Add -Werror support

Christophe Lyon writes: > When --enable-werror is enabled when running the top-level configure, > it passes --enable-werror-always to subdirs. Some of them, like > libgcc, ignore it. > > This patch adds support for it, enabled only for aarch64, to avoid > breaking bootstrap for other targets. > >

Re: [PATCH 2/3] aarch64: libgcc: add prototypes in cpuinfo

> On 8 Oct 2024, at 11:57, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Christophe Lyon writes: >> On Fri, 4 Oct 2024 at 10:00, Kyrylo Tkachov wrote: >>> >>> >>> On 3 Oct 2024, at 21:44, Christophe Lyon wrote: External

Re: [PATCH] libgcc: Use inline variable instead of function-local static

On Tue, Oct 08, 2024 at 10:57:06AM +0100, Jonathan Wakely wrote: > Whoops, yes of course. Raising the topic of __cxa_guard_acquire was my > fault, and doesn't apply here, sorry. > > But we still want to get rid of the STB_GNU_UNIQUE binding for the > static variables, don't we? I think it is the

Re: [PATCH 2/3] aarch64: libgcc: add prototypes in cpuinfo

Christophe Lyon writes: > On Fri, 4 Oct 2024 at 10:00, Kyrylo Tkachov wrote: >> >> >> >> > On 3 Oct 2024, at 21:44, Christophe Lyon >> > wrote: >> > >> > External email: Use caution opening links or attachments >> > >> > >> > Add prototypes for __init_cpu_features_resolver and >> > __init_cpu_f

Re: [PATCH] libgcc: Use inline variable instead of function-local static

On Tue, 8 Oct 2024 at 10:28, Jakub Jelinek wrote: > > On Tue, Oct 08, 2024 at 08:18:56PM +1100, Nathaniel Shead wrote: > > On Tue, Oct 01, 2024 at 12:36:21PM +0200, Jakub Jelinek wrote: > > > On Tue, Oct 01, 2024 at 11:10:03AM +0100, Jonathan Wakely wrote: > > > > Let's use an inline variable. A f

Re: [PING] [PATCH] i386: Implement Thread Local Storage on Windows

I also tried using UNSPEC_PCREL instead of making a new UNSPEC_TLS_WIN32 enumeration, but it unfortunately didn't recognise the resulting RTL. Perhaps something for another day On Tue, Oct 8, 2024 at 5:19 PM Eric Botcazou wrote: > > Thanks for the patch! You certainly worked that out faster than

Re: [PATCH] aarch64: Optimise calls to ldexp with SVE FSCALE instruction

Tamar Christina writes: >> -Original Message- >> From: Kyrylo Tkachov >> Sent: Thursday, October 3, 2024 4:45 PM >> To: Richard Sandiford >> Cc: Soumya AR ; Tamar Christina >> ; gcc-patches@gcc.gnu.org; Richard Earnshaw >> ; Jennifer Schmitz ; >> Pengxuan Zheng (QUIC) >> Subject: Re: [P

Re: [PING] [PATCH] i386: Implement Thread Local Storage on Windows

Sorry for not being fast enough to rewrite the patch on my end to integrate your changes (I'm maintaining this patch for both gcc 14 and master at the same time, which is a little complicated), but I appreciate the help :) How did you figure out the issue so quickly? I was going in circles trying t

Re: [PATCH] libgcc: Use inline variable instead of function-local static

On Tue, Oct 08, 2024 at 08:18:56PM +1100, Nathaniel Shead wrote: > On Tue, Oct 01, 2024 at 12:36:21PM +0200, Jakub Jelinek wrote: > > On Tue, Oct 01, 2024 at 11:10:03AM +0100, Jonathan Wakely wrote: > > > Let's use an inline variable. A function-local static requires > > > __cxa_guard_acquire, whic

Re: [PATCH v2 2/2] Adjust testcase after relax O2 vectorization.

On Tue, Oct 8, 2024 at 11:14 AM Hongtao Liu wrote: > > On Tue, Oct 8, 2024 at 4:56 PM Richard Biener > wrote: > > > > On Tue, Oct 8, 2024 at 10:36 AM liuhongt wrote: > > > > > > gcc/testsuite/ChangeLog: > > > > > > * gcc.dg/fstack-protector-strong.c: Adjust > > > scan-assembler-t

[PATCH] libgcc: Use inline variable instead of function-local static

On Tue, Oct 01, 2024 at 12:36:21PM +0200, Jakub Jelinek wrote: > On Tue, Oct 01, 2024 at 11:10:03AM +0100, Jonathan Wakely wrote: > > Let's use an inline variable. A function-local static requires > > __cxa_guard_acquire, which (for some targets, including the ones > > affected by this change) uses

Re: [PATCH v2 1/2] Enable vectorization for unknown tripcount in very cheap cost model but disable epilog vectorization.

Richard Biener writes: > On Tue, Oct 8, 2024 at 10:36 AM liuhongt wrote: >> >> >So should we adjust very-cheap to allow niter peeling as proposed or >> >should we switch the default at -O2 to cheap? >> I prefer the former. >> >> Update in V2: >> Adjust testcase after relax O2 vectorization. >> >>

Re: [PATCH v2 2/2] Adjust testcase after relax O2 vectorization.

On Tue, Oct 8, 2024 at 4:56 PM Richard Biener wrote: > > On Tue, Oct 8, 2024 at 10:36 AM liuhongt wrote: > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/fstack-protector-strong.c: Adjust > > scan-assembler-times. > > * gcc.dg/graphite/scop-6.c: Add > > -Wno-aggre

[PATCH v14 2/4] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

The old name was misleading. While at it, also rename some temporary variables that are used with this function, for consistency. Link: gcc/ChangeLog: *

[PATCH v14 4/4] c: Add __countof__ operator

This operator is similar to sizeof but can only be applied to an array, and returns its number of elements. FUTURE DIRECTIONS: - We should make it work with array parameters to functions, and somehow magically return the number of elements of the array, regardless of it being really a poin

[PATCH v14 3/4] Merge definitions of array_type_nelts_top()

There were two identical definitions, and none of them are available where they are needed for implementing __nelementsof__. Merge them, and provide the single definition in gcc/tree.{h,cc}, where it's available for __nelementsof__, which will be added in the following commit. gcc/ChangeLog:

[PATCH v14 1/4] contrib/: Add support for Cc: and Link: tags

contrib/ChangeLog: * gcc-changelog/git_commit.py (GitCommit): Add support for 'Cc: ' and 'Link: ' tags. Cc: Jason Merrill Signed-off-by: Alejandro Colomar --- contrib/gcc-changelog/git_commit.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/contrib/gcc

[PATCH v14 0/4] c: Add __countof__ operator

Hi! Here's v14 with some changes: A) Rename s/__lengthof__/__countof__/ (rationale(s) below). B) Remove the concept "top-level array" from the docs (rationale below). At the bottom of this email is a range diff comparing to v13. A.1) WG14 had only weak consensus for prefering lengthof over

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

On Tue, Oct 8, 2024 at 3:23 AM wrote: > > From: Pan Li > > This patch would like to support the form 3 and form 4 of the scalar signed > integer SAT_SUB. Aka below example: > > Form 3: > #define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \ > T __attribute__((noinline))

  1   2   >