Re: [PATCHv2, expand] Add const0 move checking for CLEAR_BY_PIECES optabs

Hi Jeff, 在 2024/8/5 23:11, Jeff Law 写道: > We'll probably need Richard S. or someone else to chime in on the actual > patch, but yea, if they can leverage stp, it's likely going to be better than  > actual vectors. > > Do we have a testcase for this issue or was it something you just happened to 

Re: [x86_64 PATCH] Support memory destinations and wide immediate constants in STV.

On Mon, Aug 5, 2024 at 5:50 PM Roger Sayle wrote: > > > Hi Uros, > Very many thanks for the quick review and approval. Here's another. > > This patch implements two improvements/refinements to the i386 backend's > Scalar-To-Vector (STV) pass. The first is to support memory destinations > in bina

[PATCH] wide-int: Fix up mul_internal overflow checking [PR116224]

Hi! The following testcase is miscompiled, because wi::mul for (_BitInt(65))-15 times (_BitInt(65))-15 computes the right value (_BitInt(65))225, but sets *overflow to wi::OVF_UNKNOWN as that it overflowed when it didn't. Even signed operands are unpacked as unsigned but because they are implicit

Re: [PATCH] wide-int: Fix up mul_internal overflow checking [PR116224]

On Tue, 6 Aug 2024, Jakub Jelinek wrote: > Hi! > > The following testcase is miscompiled, because wi::mul for (_BitInt(65))-15 > times (_BitInt(65))-15 computes the right value (_BitInt(65))225, but > sets *overflow to wi::OVF_UNKNOWN as that it overflowed when it didn't. > > Even signed operand

Re: [PATCH] wide-int: Fix up mul_internal overflow checking [PR116224]

Jakub Jelinek writes: > Hi! > > The following testcase is miscompiled, because wi::mul for (_BitInt(65))-15 > times (_BitInt(65))-15 computes the right value (_BitInt(65))225, but > sets *overflow to wi::OVF_UNKNOWN as that it overflowed when it didn't. > > Even signed operands are unpacked as un

[COMMITTED 3/9] ada: Use fully qualified in the runtime library

From: Viljar Indus gcc/ada/ * libgnarl/s-taprop__mingw.adb: Use fully qualified names to avoid ambiguity. * libgnarl/s-taprop__posix.adb: Likewise. * libgnarl/s-taprop__qnx.adb: Likewise. * libgnarl/s-taprop__rtems.adb: Likewise. Tested on x86_64-pc-linux

[COMMITTED 2/9] ada: Fix propagation of SPARK_Mode for renaming-as-body

From: Yannick Moy The value of SPARK_Mode associated with a renaming-as-body might not be the correct one, when the private part of the package containing the declaration has SPARK_Mode Off while the public part has SPARK_Mode On. This may lead to analysis of code by GNATprove that should not be

[COMMITTED 1/9] ada: Reject use-clause conflicts in the run-time library

From: Bob Duff This patch fixes a bug where GNAT would fail to detect certain errors when compiling the run-time library. In particular, if two overloaded homographs are both directly visible, it would pick one, rather than complaining about the ambiguity. The problem was that some special-purp

[COMMITTED 7/9] ada: GNAT-LLVM compiler crash on container aggregates with iterators

From: Gary Dismukes Recent fixes for container aggregates with iterated element associations exposed a latent bug with loops that are wrapped in blocks, where the loop entity's scope was not adjusted to reflect the new enclosing block scope. gcc/ada/ * sem_ch5.adb (Analyze_Loop_Statemen

[COMMITTED 9/9] ada: Fix error in GNATprove inlining with array concatenation

From: Yannick Moy Wrong interpretation of the type of the concatenation can lead to a spurious error in GNATprove when inlining code. Now fixed. gcc/ada/ * sem_ch4.adb (Analyze_Concatenation_Rest): Do not add a wrong interpretation of the concatenation, using the type of the ope

[COMMITTED 6/9] ada: Spurious error on the default value of a derived scalar type

From: Javier Miranda When the aspect Default_Value is inherited by a derived scalar type, and both the parent type T and the derived type DT are declared in the same scope, a spurious error may be reported. This occurs if a subprogram declared in the same scope has a parameter of type DT with a d

[COMMITTED 4/9] ada: Assert failure in repinfo

From: Javier Miranda Using switch gnatR4, the frontend crashes when generating information for a private record type. gcc/ada/ * repinfo.adb (List_Record_Info): Handle private record types. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/repinfo.adb | 6 +- 1 file

[r15-2739 Regression] FAIL: gfortran.dg/class_transformational_1.f90 -O3 -g (test for excess errors) on Linux/x86_64

On Linux/x86_64, 4cb07a38233aadb4b389a6e5236c95f52241b6e0 is the first bad commit commit 4cb07a38233aadb4b389a6e5236c95f52241b6e0 Author: Paul Thomas Date: Tue Aug 6 06:42:27 2024 +0100 Fortran: Fix class transformational intrinsic calls [PR102689] caused FAIL: gfortran.dg/class_transfor

[COMMITTED 8/9] ada: Implement type inference for generic parameters

From: Bob Duff ...based on previous work that added Gen_Assocs_Rec. Minor cleanup of that previous work. gcc/ada/ * sem_ch12.adb: Implement type inference for generic parameters. (Maybe_Infer_One): Forbid inference of anonymous subtypes and types. (Inference_Reas

[COMMITTED 5/9] ada: Use fully qualified in more library files

From: Viljar Indus gcc/ada/ * libgnarl/s-interr__hwint.adb: Use fully qualified names to avoid ambiguity. * libgnarl/s-taprop__qnx.adb: Likewise. Tested on x86_64-pc-linux-gnu, committed on master. --- gcc/ada/libgnarl/s-interr__hwint.adb | 11 ++- gcc/ada/libg

[PATCH] testsuite: Fix up pr116037.c test [PR116245]

Hi! The test FAILs on big endian targets, because VV is a vector of unsigned __int128 and VC vector of unsigned char and so ((VC) vv)[0] is 0x01 on little endian but 0xff on big endian and PDP endian. As I believe it is intentional to test it as it is written on little endian, the following patch

Re: [PATCH] testsuite: Fix up pr116037.c test [PR116245]

On Tue, 6 Aug 2024, Jakub Jelinek wrote: > Hi! > > The test FAILs on big endian targets, because VV is a vector of unsigned > __int128 > and VC vector of unsigned char and so ((VC) vv)[0] is 0x01 on little endian > but 0xff on big endian and PDP endian. > As I believe it is intentional to test i

Re: [PATCH] RISC-V: Minimal support for Zimop extension.

Hi Jeff, 2.43 was released over an weekend.  Is it possible to let it be supported after 2.44? cc Nick and jan. I don't think it's critical enough to backport to 2.43.  I'd just put it on the trunk so that it's available in 2.44. It might be worth adding it to the 2.43 branch as well. It i

[PATCH] c++: Improve fixits for incorrect explicit instantiations

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- When forgetting the '<>' on an explicit specialisation, the suggested fixit hint suggests to add 'template <>', but naively applying will cause nonsense results like 'template template <> struct S {};'. Instead check if we

Re: [PATCH v1 1/3] aarch64: store signing key and signing method in DWARF _Unwind_FrameState

Sorry for the slow review. Matthieu Longo writes: > This patch is only a refactoring of the existing implementation > of PAuth and returned-address signing. The existing behavior is > preserved. > > _Unwind_FrameState already contains several CIE and FDE information > (see the attributes below th

Re: [PATCH v1 2/3] libgcc: hide CIE and FDE data for DWARF architecture extensions behind a handler.

Matthieu Longo writes: > This patch provides a new handler MD_ARCH_FRAME_STATE_T to hide an > architecture-specific structure containing CIE and FDE data related > to DWARF architecture extensions. > > Hiding the architecture-specific attributes behind a handler has the > following benefits: > 1.

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

> On 5 Aug 2024, at 18:00, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov writes: >>> On 5 Aug 2024, at 12:01, Richard Sandiford >>> wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> >>> Jennifer S

Re: [PATCH v2] Rearrange SLP nodes with duplicate statements. [PR98138]

Pinging this for a review and/or further feedback. Thanks, Manolis On Wed, Jun 26, 2024 at 3:06 PM Manolis Tsamis wrote: > > This change checks when a two_operators SLP node has multiple occurrences of > the same statement (e.g. {A, B, A, B, ...}) and tries to rearrange the > operands > so that

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

Kyrylo Tkachov writes: >> On 5 Aug 2024, at 18:00, Richard Sandiford wrote: >> >> External email: Use caution opening links or attachments >> >> >> Kyrylo Tkachov writes: On 5 Aug 2024, at 12:01, Richard Sandiford wrote: External email: Use caution opening links or atta

[PATCH] tree-optimization/116241 - ICE with SLP condition reduction

When there's a conversion in front of a SLP condition reduction the code following the reduc-idx SLP chain fails because it assumes there's only COND_EXPRs. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/116241 * tree-vect-loop.cc (vect_create_ep

Re: [PATCH 01/11] OpenMP/PolyInt: Pass poly-int structures by address to OMP libs.

On Mon, May 27, 2024 at 10:36:16AM +0530, Tejas Belagod wrote: > Currently poly-int type structures are passed by value to OpenMP runtime > functions for shared clauses etc. This patch improves on this by passing > around poly-int structures by address to avoid copy-overhead. > > gcc/ChangeLog >

Re: [PATCH 02/11] AArch64: Add test cases for SVE types in OpenMP shared clause.

On Mon, May 27, 2024 at 10:36:17AM +0530, Tejas Belagod wrote: > This patch tests various shared clauses with SVE types. It also adds a test > scaffold to run OpenMP tests in under the gcc.target testsuite. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/sve/omp/aarch64-sve-omp.exp:

Re: [RFC][PATCH] SVE intrinsics: Fold svdiv (svptrue, x, x) to ones

> On 6 Aug 2024, at 12:44, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov writes: >>> On 5 Aug 2024, at 18:00, Richard Sandiford >>> wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> >>> Kyrylo Tka

Re: [PATCH 03/11] AArch64: Diagnose OpenMP offloading when SVE types involved.

On Mon, May 27, 2024 at 10:36:18AM +0530, Tejas Belagod wrote: > The target clause in OpenMP is used to offload loop kernels to accelarator > peripeherals. target's 'map' clause is used to move data from and to the > accelarator. When the data is SVE type, it may not be suitable because of > vari

Re: [PATCH 04/11] AArch64: Test OpenMP lastprivate clause for various constructs.

On Mon, May 27, 2024 at 10:36:19AM +0530, Tejas Belagod wrote: > This patch tests various OpenMP lastprivate clause with SVE object types in > various construct contexts. > > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/sve/omp/lastprivate.c: New test. This is a dg-do compile test, so

Re: [PATCH 05/11] AArch64: Test OpenMP threadprivate clause on SVE type.

On Mon, May 27, 2024 at 10:36:20AM +0530, Tejas Belagod wrote: > This patch adds a test for ensuring threadprivate clause works for SVE type > objects. > > gcc/testsuite/ChangeLog > > * gcc.target/aarch64/sve/omp/threadprivate.c: New test. Guess this would be better a runtime testcase.

[PATCH] genoutput: Accelerate the place_operands function.

With the increase in the number of modes and patterns for some backend architectures, the place_operands function becomes a bottleneck in the speed of genoutput, and may even become a bottleneck in the overall speed of building the GCC project. This patch aims to accelerate the place_operands funct

Re: [PATCH v1] Match: Support form 1 for scalar signed integer .SAT_ADD

On Tue, Aug 6, 2024 at 3:21 AM Li, Pan2 wrote: > > Hi Richard, > > It looks like the plus will have additional convert to unsigned in int8 and > int16, see below example in test.c.006t.gimple. > And we need these convert ops in one matching pattern to cover all int scalar > types. Ah, yeah - th

Re: [PATCH 06/11] AArch64: Test OpenMP user-defined reductions with SVE types.

On Mon, May 27, 2024 at 10:36:21AM +0530, Tejas Belagod wrote: > This patch tests user-defined reductions on various constructs with objects > of SVE type. > > gcc/testsuite/ChangeLog > > * gcc.target/aarch64/sve/omp/udr-sve.c: New test. > --- > .../gcc.target/aarch64/sve/omp/udr-sve.c

[PATCH v2] c++/modules: Ensure deduction guides are always reachable [PR115231]

On Fri, Jul 26, 2024 at 01:17:57PM -0400, Jason Merrill wrote: > On 7/26/24 12:52 AM, Nathaniel Shead wrote: > > On Tue, Jul 23, 2024 at 04:17:22PM -0400, Jason Merrill wrote: > > > On 6/15/24 10:29 PM, Nathaniel Shead wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

Re: [PATCH 07/11] AArch64: Test OpenMP uniform clause on SVE types.

On Mon, May 27, 2024 at 10:36:22AM +0530, Tejas Belagod wrote: > This patch tests if simd uniform clause works with SVE types in simd regions. > > gcc/testsuite/ChangeLog > > * gcc.target/aarch64/sve/omp/simd-uniform.c: New test. > --- > .../gcc.target/aarch64/sve/omp/simd-uniform.c | 71 +

Re: [PATCH 08/11] AArch64: Test OpenMP simd aligned clause with SVE types.

On Mon, May 27, 2024 at 10:36:23AM +0530, Tejas Belagod wrote: > This patch tests simd aligned clause and their interaction with SVE types. > > gcc/testsuite/ChangeLog > > * gcc.target/aarch64/sve/omp/simd-aligned.c: New test. > --- > .../gcc.target/aarch64/sve/omp/simd-aligned.c | 50

[PATCH] gimple ssa: Put SCCOPY logic into a class

Hello everybody, In pr113054[1] Andrew said that he doesn't like the 'dead_stmts' static variable I used when implementing the sccopy pass. We agreed that wrapping the relevant code from the pass in a class would be most likely the best solution. Here is a patch that does exactly that. I waited

Re: [PATCH 09/11] AArch64: Diagnose OpenMP linear clause for SVE type objects.

On Mon, May 27, 2024 at 10:36:24AM +0530, Tejas Belagod wrote: > This patch tests if SVE object types if applied to linear clause is diagnosed > as expected. > > gcc/testsuite/ChangeLog > > * gcc.target/aarch64/sve/omp/linear.c: New test. > --- > .../gcc.target/aarch64/sve/omp/linear.c

Re: [PATCH 10/11] AArch64: Test OpenMP depend clause and its variations on SVE types

On Mon, May 27, 2024 at 10:36:25AM +0530, Tejas Belagod wrote: > This patch adds a test to test depend clause and its various dependency > variations with SVE type objects. > > gcc/testsuite/ChangeLog > > * gcc.target/aarch64/sve/omp/depend-1.c: New test. > --- > .../gcc.target/aarch64/sve

Re: [PATCH 11/11] AArch64: Diagnose SVE type objects when applied to OpenMP doacross clause.

On Mon, May 27, 2024 at 10:36:26AM +0530, Tejas Belagod wrote: > This patch tests if SVE type objects when applied to doacross clause are > correctly diagnosed. > > gcc/testsuite/ChangeLog > > * gcc.target/aarch64/sve/omp/doacross.c: New test. > --- > .../gcc.target/aarch64/sve/omp/doacros

[RFC v4 0/4] c: Add __lengthof__ operator

Hi! v4: - Only evaluate the operand if the top array is VLA. Inner VLAs are ignored. [Joseph, Martin] This proved very useful for compile-time diagnostics, since we have more cases that are constant expressions. - Document the evaluation rules, which are unique to this operator (s

[RFC v4 1/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: https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120 Cc: Gabriel Ravier Cc: Marti

[RFC v4 2/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 __lengthof__(). Merge them, and provide the single definition in gcc/tree.{h,cc}, where it's available for __lengthof__(). Signed-off-by: Alejandro Colomar --- gcc/cp/cp-tree.h

[RFC v4 4/4] testsuite: Add tests for __lengthof__

I've compiled those files manually, and they behave as expected. But within the test-suite, they don't seem to work: FAIL: gcc.dg/lengthof-compile.c (test for excess errors) FAIL: gcc.dg/lengthof.c (test for excess errors) Signed-off-by: Alejandro Colomar --- gcc/testsuite/gcc.

[RFC v4 3/4] c: Add __lengthof__() operator (n2529)

This operator is similar to sizeof() but can only be applied to an array, and returns its length (number of elements). FUTURE DIRECTIONS: We could make it work with array parameters to functions, and somehow magically return the length designator of the array, regardless o

Re: [RFC v4 0/4] c: Add __lengthof__ operator

On Tue, Aug 06, 2024 at 02:22:38PM GMT, Alejandro Colomar wrote: > Hi! > > v4: > > - Only evaluate the operand if the top array is VLA. Inner VLAs are >ignored. [Joseph, Martin] >This proved very useful for compile-time diagnostics, since we have >more cases that are constant expre

[PATCH v2] Vect: Make sure the lhs type of .SAT_TRUNC has its mode precision [PR116202]

From: Pan Li The .SAT_TRUNC vect pattern recog is valid when the lhs type has its mode precision. For example as below, QImode with 1 bit precision like _Bool is invalid here. g_12 = (long unsigned int) _2; _13 = MIN_EXPR ; _3 = (_Bool) _13; The above pattern cannot be recog as .SAT_TRUNC (g_1

RE: [PATCH v1] Match: Support form 1 for scalar signed integer .SAT_ADD

> Ah, yeah - that's the usual (premature) frontend optimization to > shorten operations after the standard > mandated standard conversion (to 'int' in this case). Thanks Richard for confirmation, let me refine the matching in v2. Pan -Original Message- From: Richard Biener Sent: Tuesda

[PATCH] tree-optimization/116166 - forward jump-threading going wild

Currently the forward threader isn't limited as to the search space it explores and with it now using path-ranger for simplifying conditions it runs into it became pretty slow for degenerate cases like compiling insn-emit.cc for RISC-V esp. when compiling for a host with LOGICAL_OP_NON_SHORT_CIRCUI

Re: [PATCH] gimple ssa: Put SCCOPY logic into a class

On Tue, 6 Aug 2024, Filip Kastl wrote: > Hello everybody, > > In pr113054[1] Andrew said that he doesn't like the 'dead_stmts' static > variable I used when implementing the sccopy pass. We agreed that wrapping > the relevant code from the pass in a class would be most likely the best > solution

Re: [PATCH] gimple ssa: Put SCCOPY logic into a class

On Tue 2024-08-06 15:14:32, Richard Biener wrote: > On Tue, 6 Aug 2024, Filip Kastl wrote: > > > Hello everybody, > > > > In pr113054[1] Andrew said that he doesn't like the 'dead_stmts' static > > variable I used when implementing the sccopy pass. We agreed that wrapping > > the relevant code f

Re: [PATCH v2] Vect: Make sure the lhs type of .SAT_TRUNC has its mode precision [PR116202]

On Tue, Aug 6, 2024 at 2:59 PM wrote: > > From: Pan Li > > The .SAT_TRUNC vect pattern recog is valid when the lhs type has > its mode precision. For example as below, QImode with 1 bit precision > like _Bool is invalid here. > > g_12 = (long unsigned int) _2; > _13 = MIN_EXPR ; > _3 = (_Bool) _

Re: [PATCH] RISC-V: Minimal support for Zimop extension.

On 8/6/24 3:31 AM, Nick Clifton wrote: Hi Jeff, 2.43 was released over an weekend.  Is it possible to let it be supported after 2.44? cc Nick and jan. I don't think it's critical enough to backport to 2.43.  I'd just put it on the trunk so that it's available in 2.44. It might be worth ad

Re: [RFC v4 0/4] c: Add __lengthof__ operator

Am Dienstag, dem 06.08.2024 um 14:22 +0200 schrieb Alejandro Colomar: > Hi! > > - The tests seem to work as expected if I compile them manually, and >run (the one that should be run) as a normal program. The one that >should not be run also gives the expected diagnostics. >Can anyone

Re: [PATCH] c++: remove function/var concepts code

On Mon, Aug 05, 2024 at 09:56:20PM -0400, Patrick Palka wrote: > On Fri, 2 Aug 2024, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? > > > > -- >8 -- > > This patch removes vestigial Concepts TS code as discussed in > >

Re: [PATCHv2, expand] Add const0 move checking for CLEAR_BY_PIECES optabs

On 8/6/24 1:20 AM, HAO CHEN GUI wrote: Hi Jeff, 在 2024/8/5 23:11, Jeff Law 写道: We'll probably need Richard S. or someone else to chime in on the actual patch, but yea, if they can leverage stp, it's likely going to be better than actual  vectors. Do we have a testcase for this issue or was

[PATCH] c++: fold calls to std::forward_like [PR96780]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This extends our folding of cast-like standard library functions to also include C++23's std::forward_like. PR c++/96780 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold) : Fold calls t

Re: [PATCH] c++: fold calls to std::forward_like [PR96780]

On Tue, Aug 06, 2024 at 10:01:22AM -0400, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > look OK for trunk? Looks simple & good. Reviewed-by: Marek Polacek > -- >8 -- > > This extends our folding of cast-like standard library functions > to also include

[PATCH v1 0/4] dwarf2: add hooks for architecture-specific CFIs

Architecture-specific CFI directives are currently declared an processed among others architecture-independent CFI directives in gcc/dwarf2* files. This approach creates confusion, specifically in the case of DWARF instructions in the vendor space and using the same instruction code. Such a clas

[PATCH v1 1/4] Rename REG_CFA_TOGGLE_RA_MANGLE to REG_CFA_NEGATE_RA_STATE

The current name REG_CFA_TOGGLE_RA_MANGLE is not representative of what it really is, i.e. a register to represent several states, not only a binary one. Same for dwarf2out_frame_debug_cfa_toggle_ra_mangle. gcc/ChangeLog: * combine-stack-adj.cc (no_unhandled_cfa): Rename.

[PATCH v1 3/4] aarch64 testsuite: explain expectections for pr94515* tests

gcc/testsuite/ChangeLog: * g++.target/aarch64/pr94515-1.C: Improve test documentation. * g++.target/aarch64/pr94515-2.C: Same. --- gcc/testsuite/g++.target/aarch64/pr94515-1.C | 8 ++ gcc/testsuite/g++.target/aarch64/pr94515-2.C | 28 +++- 2 files changed, 30

[PATCH v1 2/4] dwarf2: add hooks for architecture-specific CFIs

Architecture-specific CFI directives are currently declared an processed among others architecture-independent CFI directives in gcc/dwarf2* files. This approach creates confusion, specifically in the case of DWARF instructions in the vendor space and using the same instruction code. Such a clash

[PATCH v1 4/4] dwarf2: store the RA state in CFI row

On AArch64, the RA state informs the unwinder whether the return address is mangled and how, or not. This information is encoded in a boolean in the CFI row. This binary approach prevents from expressing more complex configuration, as it is the case with PAuth_LR introduced in Armv9.5-A. This patc

RE: [PATCH v2] Vect: Make sure the lhs type of .SAT_TRUNC has its mode precision [PR116202]

> OK. Thanks Richard. Just notice we can put type_has_mode_precision_p as the first condition to avoid unnecessary pattern matching (which is heavy), will commit with this change if no surprise from test suite. From: > + if (gimple_unsigned_integer_sat_trunc (lhs, ops, NULL) > + && type_

Re: [RFC v4 0/4] c: Add __lengthof__ operator

Hi Martin, On Tue, Aug 06, 2024 at 03:37:13PM GMT, Martin Uecker wrote: > Am Dienstag, dem 06.08.2024 um 14:22 +0200 schrieb Alejandro Colomar: > > Hi! > > > > - The tests seem to work as expected if I compile them manually, and > >run (the one that should be run) as a normal program. The o

Re: [PATCH v5 1/1] RISC-V: Add support for XCVbitmanip extension in CV32E40P

On 8/4/24 12:35 PM, Mary Bennett wrote: Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett H

Re: [PATCH v1 4/4] dwarf2: store the RA state in CFI row

On Tue, Aug 06, 2024 at 03:07:44PM +0100, Matthieu Longo wrote: > On AArch64, the RA state informs the unwinder whether the return address > is mangled and how, or not. This information is encoded in a boolean in > the CFI row. This binary approach prevents from expressing more complex > configurat

[PATCH] Support if conversion for switches

The gimple-if-to-switch pass converts if statements with multiple equal checks on the same value to a switch. This breaks vectorization which cannot handle switches. Teach the tree-if-conv pass used by the vectorizer to handle simple switch statements, like those created by if-to-switch earlier. T

[wwwdocs] gcc-15: Mention c++ header dependency changes () in porting_to.html

Hi, I recently had to add '#include ' to a program to compile it with the latest trunk GCC due to https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659176.html So I thought I might create the GCC 15 porting_to.html page and add an entry about this (I just copied the entry from GCC 14 porting

Re: [PATCH] ASAN: call initialize_sanitizer_builtins for hwasan [PR115205]

On Tue, May 28, 2024 at 8:28 PM Andrew Pinski wrote: > > Sometimes initialize_sanitizer_builtins is not called before emitting > the asan builtins with hwasan. In the case of the bug report, there > was a path with the fortran front-end where it was not called. > So let's call it in asan_instrumen

Re: [RFC v4 0/4] c: Add __lengthof__ operator

Am Dienstag, dem 06.08.2024 um 16:12 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Tue, Aug 06, 2024 at 03:37:13PM GMT, Martin Uecker wrote: > > Am Dienstag, dem 06.08.2024 um 14:22 +0200 schrieb Alejandro Colomar: > > > Hi! > > > > > > - The tests seem to work as expected if I compile th

Re: [wwwdocs] gcc-15: Mention c++ header dependency changes () in porting_to.html

On Tue, 6 Aug 2024, Filip Kastl wrote: > So I thought I might create the GCC 15 porting_to.html page and add an > entry about this (I just copied the entry from GCC 14 porting_to.html). Nice. > Ha! As I'm writing this I noticed that actually Jonathan predicted this > and suggested a correspond

Re: [PATCH] rs6000, document built-ins vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros

Steve: Agreed the documentation only specifies unsigned char argument for the two built-ins. Do you think we should add support signed char arguments in addition to the documented unsigned char arguments? Do you see any situations where a user might want to to have both signed and unsigned

Re: [RFC v3 3/3] c: Add __lengthof__() operator

On Aug 5, 2024, at 16:59, Alejandro Colomar wrote: The “counted-by” attribute currently is not in the TYPE system, and we plan to add it into the TYPE system later through language standard (or an GCC extension). If that happens, then both the “sizeof” and the “__lengthof__” operators should

Re: [RFC] libstdc++: Replace Ryu with Teju Jagua for float.

Cassio Neri writes: > Implement the template function teju_jagua which finds the shortest > representation of a floating-point number. The floating-point type is a > template parameter and the implementation is generic enough to handle all > floating-point types of interest, namely, IEEE 754, std

Re: [PATCH] c++: fold calls to std::forward_like [PR96780]

On 8/6/24 10:01 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? I might add it after std::forward instead of at the bottom? OK either way. -- >8 -- This extends our folding of cast-like standard library functions to also include C++2

Re: [RFC v4 0/4] c: Add __lengthof__ operator

Hi Martin, On Tue, Aug 06, 2024 at 04:43:27PM GMT, Martin Uecker wrote: > > When running `make check -j24 -Orecurse |& tee log`, this is what I see: > > > > FAIL: gcc.dg/lengthof-compile.c (test for excess errors) > > > > Is there any way to see more details? > > See gcc/testsuite/g

Re: [RFC v4 0/4] c: Add __lengthof__ operator

Hi, Alex, I noticed that all your 4 versions of the patches and the corresponding discussion are all in the same email thread, it’s very inconvenient to read. Can you start a new email thread for each of the new version of the patch? (i.e, Please not reply to the previous version when you have a

[PATCH] RISC-V: Fix format-diag warning from improperly formatted url

gcc/ChangeLog: PR target/116152 * config/riscv/riscv.cc (riscv_option_override): Fix url formatting. gcc/testsuite/ChangeLog: * gcc.target/riscv/predef-9.c: Update testcase. Co-authored-by: Jakub Jelinek Signed-off-by: Patrick O'Neill --- Tested using rv64gc.

[PATCH] c++: further concept_check_p clean-up

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Patrick noticed a few more concept_check_p checks that can be removed now. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expression): Remove concept_check_p check. (cxx_eval_outermost_constant_expr): Likewise

Re: [PATCH] RISC-V: Fix format-diag warning from improperly formatted url

On Tue, 06 Aug 2024 09:07:26 PDT (-0700), Patrick O'Neill wrote: gcc/ChangeLog: PR target/116152 * config/riscv/riscv.cc (riscv_option_override): Fix url formatting. gcc/testsuite/ChangeLog: * gcc.target/riscv/predef-9.c: Update testcase. Co-authored-by: Jaku

[Committed] RISC-V: Fix format-diag warning from improperly formatted url

On 8/6/24 09:12, Palmer Dabbelt wrote: On Tue, 06 Aug 2024 09:07:26 PDT (-0700), Patrick O'Neill wrote: gcc/ChangeLog: PR target/116152 * config/riscv/riscv.cc (riscv_option_override): Fix url   formatting. gcc/testsuite/ChangeLog: * gcc.target/riscv/predef-9.c: Update testc

[PATCH 0/3] libcpp: improve x86 vectorized helpers

Hello! As discussed, I'm sending patches that reimplement our SSE4.2 search_line_fast helper with SSSE3, and then add the corresponding AVX2 helper. They are on top of Andi's "Remove MMX code path in lexer" patch, which was approved, but not committed yet (Andi, can you push your own patch?). App

[PATCH 1/3] libcpp: configure: check for AVX2 instead of SSE4

Upcoming patches first drop Binutils ISA support from SSE4.2 to SSSE3, then bump it to AVX2. Instead of fiddling with detection, just bump our configure check to AVX2 immediately: if by some accident somebody builds GCC without AVX2 support in the assembler, they will get SSE2 vectorized lexer, whi

[PATCH 2/3] libcpp: replace SSE4.2 helper with an SSSE3 one

Since the characters we are searching for (CR, LF, '\', '?') all have distinct ASCII codes mod 16, PSHUFB can help match them all at once. libcpp/ChangeLog: * lex.cc (search_line_sse42): Replace with... (search_line_ssse3): ... this new function. Adjust the use... (init_v

[PATCH 3/3] libcpp: add AVX2 helper

Use the same PSHUFB-based matching as in the SSSE3 helper, just 2x wider. Directly use the new helper if __AVX2__ is defined. It makes the other helpers unused, so mark them inline to prevent warnings. Rewrite and simplify init_vectorized_lexer. libcpp/ChangeLog: * files.cc (read_file_g

Re: [RFC v4 0/4] c: Add __lengthof__ operator

[CC += David, Florian, Andreas] On Tue, Aug 06, 2024 at 03:59:11PM GMT, Qing Zhao wrote: > Hi, Alex, Hi Qing, > I noticed that all your 4 versions of the patches and the > corresponding discussion are all in the same email thread, it’s very > inconvenient to read. Can you start a new email threa

Re: [RESEND PATCH v5 1/3] ifcvt: handle sequences that clobber flags in noce_convert_multiple_sets

Sam, Jakub & Robin, We had an "OK for trunk" from Jeff for v4 (see https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656907.html) and it has been two more weeks for this RESEND. I'll push this by end of this week unless I hear otherwise. Thanks, Philipp. On Fri, 26 Jul 2024 at 12:50, Sam Jame

Re: [PATCH] c++: further concept_check_p clean-up

On Tue, 6 Aug 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? LGTM > > -- >8 -- > Patrick noticed a few more concept_check_p checks that can be removed > now. > > gcc/cp/ChangeLog: > > * constexpr.cc (cxx_eval_call_expression): Remove concept_ch

[pushed] c++: zero-init and class nttp [PR94568]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A zero-initializer should not reflect the constness of what it's initializing, as it does not for initializers with different syntax. This does have mangling implications for rare C++20 code, but it seems infeasable to make the mangling dep

Re: [PATCH] tree-optimization/116166 - forward jump-threading going wild

On 8/6/24 09:12, Richard Biener wrote: Currently the forward threader isn't limited as to the search space it explores and with it now using path-ranger for simplifying conditions it runs into it became pretty slow for degenerate cases like compiling insn-emit.cc for RISC-V esp. when compiling

[PATCH 1/2] c++: alias and non-type template parm [PR116223]

Tested x86_64-pc-linux-gnu, applying to trunk and 14. -- 8< -- My r14-8291 for PR112632 introduced IMPLICIT_CONV_EXPR_FORCED to express conversions to the type of an alias template parameter. In this example, that broke deduction of X in the call to foo, so let's teach deduction to look through

[PATCH 2/2] c++: more non-type template parms [PR116223]

Tested x86_64-pc-linux-gnu, applying to trunk (not 14). -- 8< -- Building on the last patch, deduction should probably look through all IMPLICIT_CONV_EXPR like we do other conversions. One resulting regression turned out to be due to PR94568, fixed separately. The one other regression was for a

[PATCH] rust: avoid clobbering LIBS

Save LIBS around calls to AC_SEARCH_LIBS to avoid clobbering $LIBS. ChangeLog: * configure: Regenerate. * configure.ac: Save LIBS around calls to AC_SEARCH_LIBS. Signed-off-by: Marc Poulhiès Reviewed-by: Thomas Schwinge Tested-by: Thomas Schwinge --- Hello, This has already b

Re: [PATCH] c++: further concept_check_p clean-up

On 8/6/24 12:09 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- Patrick noticed a few more concept_check_p checks that can be removed now. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expression): Remove concept_check_p check.

Re: [RFC] libstdc++: Replace Ryu with Teju Jagua for float.

On Tue, 6 Aug 2024, 17:28 Andi Kleen, wrote: > Cassio Neri writes: > > > Implement the template function teju_jagua which finds the shortest > > representation of a floating-point number. The floating-point type is a > > template parameter and the implementation is generic enough to handle all >

Re: [PATCH] c++: Improve fixits for incorrect explicit instantiations

On 8/6/24 5:55 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- When forgetting the '<>' on an explicit specialisation, the suggested fixit hint suggests to add 'template <>', but naively applying will cause nonsense results like 'templ

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On 8/5/24 6:09 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 3:47 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/5/24 1:14 PM, Patrick Palka wrote: On Mon, 5 Aug 2024, Jason Merrill wrote: On 8/2/24 4:18 PM, Patrick Palka wrote: On Fr

[Committed 1/3] RISC-V: Fix comment typos

On 8/5/24 20:19, Jeff Law wrote: On 8/5/24 4:29 PM, Patrick O'Neill wrote: This fixes most of the typos I found when reading various parts of the RISC-V backend. Comment typos are always OK to fix under the "obvious" rule.  No need to wait for an ACK. Jeff Committed. Patrick

  1   2   >