Re: [PATCH] vect: Preserve OMP info for conditional stores [PR118384]

On Mon, Jan 20, 2025 at 8:57 PM Richard Sandiford wrote: > > OMP reductions are lowered into the form: > > idx = .OMP_SIMD_LANE (simuid, 0); > ... > oldval = D.anon[idx]; > newval = oldval op ...; > D.anon[idx] = newval; > > So if the scalar loop has a {0, +, 1} iv i, idx = i %

Re: [PATCH] [ifcombine] avoid dropping tree_could_trap_p [PR118514]

On Mon, Jan 20, 2025 at 8:28 PM Alexandre Oliva wrote: > > On Jan 20, 2025, Richard Biener wrote: > > > I think this is a bug in tree_could_trap_p which is indeed not considering > > out-of-bound accesses of a VAR_DECL (or any decl), but very conservatively > > handle ARRAY_REFs. > > Yeah. I eve

Re: vec::reserve semantics (was: [PATCH] c++: Handle RAW_DATA_CST in make_tree_vector_from_ctor [PR118528])

On Mon, Jan 20, 2025 at 6:26 PM Jason Merrill wrote: > > On 1/20/25 5:09 AM, Richard Biener wrote: > > On Sat, Jan 18, 2025 at 1:02 AM Jason Merrill wrote: > > >> I notice that the second argument to vec_safe_reserve is the number of > >> empty spaces to provide, rather than the new desired capac

Re: [PATCH v2 2/2] LoongArch: Improve reassociation for bitwise operation and left shift [PR 115921]

On Tue, 2025-01-21 at 11:46 +0800, Lulu Cheng wrote: > > 在 2025/1/18 下午7:33, Xi Ruoyao 写道: > /* snip */ > >   ;; This code iterator allows unsigned and signed division to be generated > >   ;; from the same template. > > @@ -3083,39 +3084,6 @@ (define_expand "rotl3" > >     } > >     }); > >  

[to-be-committed][RISC-V][PR target/116256] Fix incorrect return value for predicate

Another bug found while chasing paths to fix the remaining issues in pr116256. This case is sometimes benign when the optimizers are enabled. But could show up in a -O0 compile with some patterns I was playing around with. Basically we have a predicate that is meant to return true if bits se

[GCC16/PATCH] combine: Better split point for `(and (not X))` [PR111949]

In a similar way find_split_point handles `a+b*C`, this adds the split point for `~a & b`. This allows for better instruction selection when the target has this instruction (aarch64, arm and x86_64 are examples which have this). Built and tested for aarch64-linux-gnu. PR rtl-optmization/

[v2 PATCH 1/2] RISC-V: Support RISC-V Profiles 20/22.

This patch introduces support for RISC-V Profiles RV20 and RV22 [1], enabling developers to utilize these profiles through the -march option. [1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0 Version log: Using lowercase letters to present Profiles. Using '_' as divsor between Profile

[PATCH 2/2] RISC-V: Support RISC-V Profiles 23.

This patch introduces support for RISC-V Profiles RV23A and RV23B [1], enabling developers to utilize these profiles through the -march option. [1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-v0.7-ratification-vote Version log: Update the testcases, using lowercase letter.

[v2 PATCH 0/2] RISC-V: Support RISC-V Profiles.

This patch series introduces support for RISC-V Profiles RV20, RV22, and RV23[1][2].The updates enhance compatibility and streamline the process of leveraging RISC-V Profiles through the -march option. These additions are in line with the RISC-V standard and facilitate the adoption of these profile

Re: [PATCH v2 2/2] LoongArch: Improve reassociation for bitwise operation and left shift [PR 115921]

在 2025/1/18 下午7:33, Xi Ruoyao 写道: /* snip */ ;; This code iterator allows unsigned and signed division to be generated ;; from the same template. @@ -3083,39 +3084,6 @@ (define_expand "rotl3" } }); -;; The following templates were added to generate "bstrpick.d + alsl.d" -;;

[PATCH V5 2/2] RISC-V: Add intrinsics testcases for SiFive Xsfvcp extensions.

From: yulong This commit adds testcases for Xsfvcp. Co-Authored by: Jiawei Chen Co-Authored by: Shihua Liao Co-Authored by: Yixuan Chen gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/xsfvector/sf_vc_f.c: New test. * gcc.target/riscv/rvv/xsfvector/sf_vc_i.c: New test.

[PATCH V5 1/2] RISC-V: Add intrinsics support for SiFive Xsfvcp extensions.

From: yulong This commit adds intrinsics support for Xsfvcp extension. Diff with V4: Delete the sifive_vector.h file. Co-Authored by: Jiawei Chen Co-Authored by: Shihua Liao Co-Authored by: Yixuan Chen gcc/ChangeLog: * config/riscv/constraints.md (Ou01): New constraint. (Ou0

[PATCH V5 0/2] RISC-V: Add intrinsics support and testcases for SiFive Xsfvcp extension.

From: yulong This patch implements the Sifvie vendor extension Xsfvcp[1] support to gcc. Providing a flexible mechanism to extend application processors with custom coprocessors and variable-latency arithmetic units intrinsics. [1] https://www.sifive.com/document-file/sifive-vector-coproces

RE: gcc mode switching issue (was Re: RISC-V round_away () handling of non canonical rounding modes)

Agree, the mode-switch will take care of the frm when meet a call (covered by testcase already). 5 │ 6 │ extern size_t normalize_vl_1 (size_t vl); 7 │ extern size_t normalize_vl_2 (size_t vl); 8 │ 9 │ vfloat32m1_t 10 │ test_float_point_dynamic_frm (vfloat32m1_t op1, v

Re: [PATCH v5 1/2] [APX CFCMOV] Support APX CFCMOV in if_convert pass

Richard Biener 于2025年1月20日周一 15:45写道： > > On Mon, 20 Jan 2025, Hongyu Wang wrote: > > > Thanks Richard for willing to review this part, it is true that the > > try_cmove_arith logic adds quite a lot of special handling for > > optimization, so I reduce the logic in emit_mask_load_store to just > >

[PATCH v3] c++: fix wrong-code with constexpr prvalue opt [PR118396]

On Mon, Jan 20, 2025 at 12:39:03PM -0500, Jason Merrill wrote: > On 1/20/25 12:27 PM, Marek Polacek wrote: > > On Mon, Jan 20, 2025 at 11:46:44AM -0500, Jason Merrill wrote: > > > On 1/20/25 10:27 AM, Marek Polacek wrote: > > > > On Fri, Jan 17, 2025 at 06:38:45PM -0500, Jason Merrill wrote: > > >

[GCC-12][committed] d: Fix failing test with 32-bit compiler [PR114434]

Hi, This is patch is a backport of r15-7071, with test included ad verbatim. Since the introduction of `gdc.test/runnable/test23514.d', it's exposed an incorrect compilation when adding a 64-bit constant to a link-time address. The current cast to `size_t' causes a loss of precision, which can r

Re: [PATCH] c++/modules: Handle mismatching TYPE_CANONICAL when deduping partial specs [PR118101]

On 1/20/25 6:54 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- In r15-4862 we ensured that merging a partial specialisation would properly update its TYPE_CANONICAL. However, this confuses the deduping mechanism, since the canonical

[pushed][PR118560][LRA]: Fix typo in checking secondary memory mode for the reg class

The patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118560 Successfully tested and bootstrapped on x86-64,aarch64,ppc64le. commit 07f62ed9a7b09951f83855e19d41641b098190b1 Author: Vladimir N. Makarov Date: Mon Jan 20 17:08:50 2025 -0500 [PR118560][LRA]: Fix typo in checking secon

Re: [PATCH] c++, v2: Handle RAW_DATA_CST in add_list_candidates [PR118532]

On 1/18/25 4:06 AM, Jakub Jelinek wrote: On Fri, Jan 17, 2025 at 09:11:15PM +0100, Jakub Jelinek wrote: This is the second bug discovered today with the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html hack but then turned into proper testcases where embed-2[23].C FAILed since

Re: [PATCH] c++/modules: Check linkage of structured binding decls

On 1/19/25 4:39 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- When looking at PR c++/118513 I noticed that we don't currently check the linkage of structured binding declarations in modules. This patch adds those checks, and correct

[committed][PR target/116256] Adjust expected output in a couple testcases

I've had a long standing TODO to review the RISC-V testsuite regressions from enabling the late-combine pass (pr116256). I adjusted a few cases months ago, this adjusts a couple more were it looks like the right thing to do. All that's left after this are the vls/dup-? tests which regress in

[patch,avr] Tweak some 16-bit shifts using MUL.

u16 << 5 and u16 << 6 can be tweaked by using MUL instructions. Benefit is a better speed ratio with -Os and smaller size with -O2. No new regressions. Ok for trunk? Johann .. AVR: Tweak some 16-bit shifts by using MUL. u16 << 5 and u16 << 6 can be tweaked by using MUL instructions. Benefit

Re: [PING] [PATCH] testsuite: Fix test failing with -fimplicit-constexpr [PR118277]

On Mon, Jan 20, 2025 at 08:10:31PM +, Simon Martin wrote: > Successfully tested on x86_64-pc-linux-gnu with "make check-c++-all". > gcc/testsuite/ChangeLog: > > * g++.dg/cpp1z/constexpr-asm-5.C: Pass -fno-implicit-constexpr. LGTM. Jakub

[to-be-committed][PR target/114442] Add reservations for all insn types to xiangshan-nanhu model

The RISC-V backend has checks to verify that every used insn has an associated type and that every insn type maps to some reservation in the DFA model. If either test fails we ICE. With the cpu/isa allowed to vary independently from the tune/scheduler model, it's entirely possible (in fact tr

Re: [PATCH] c++: Don't ICE in build_class_member_access_expr during error recovery [PR118225]

On 1/4/25 10:13 AM, Simon Martin wrote: The invalid case in this PR trips on an assertion in build_class_member_access_expr that build_base_path would never return an error_mark_node, which is actually incorrect if the object involves a tree with an error_mark_node DECL_INITIAL, like here. This

Re: [PATCH] c++: Only prune capture proxies for constant variables at instantiation time [PR114292]

On 1/20/25 2:11 PM, Simon Martin wrote: Hi Jason, On 15 Jan 2025, at 22:42, Jason Merrill wrote: On 12/12/24 2:07 PM, Simon Martin wrote: We currently ICE upon the following valid (under -Wno-vla) code === cut here === void f(int c) { constexpr int r = 4; [&](auto) { int t[r * c]; }(

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Sat, 18 Jan 2025, Kees Cook wrote: > Gaining access to global variables is another gap Linux has -- e.g. we > have arrays that are sized by the global number-of-cpus variable. :) Note that it's already defined that counted_by takes an identifier for a structure member (i.e. not an expression,

[PATCH][_Hashtable] Fix hash code cache usage

Hi In my work on fancy pointer support I've decided to always cache the hash code. Doing so I spotted a bug in the management of this cache when hash functor is stateful.     libstdc++: [_Hashtable] Fix hash code cache usage when hash functor is stateful     It is wrong to reuse a cached

[PATCH, committed] Fortran: improve error message for conflicting OpenMP clauses [PR107122]

Dear all, I've pushed the following minor improvement of an error message as suggested by the reporter as obvious after regtesting in the gfortran.dg/gomp subdirectory. Thanks, Harald From 96f4ba4d19a765902af7b79aa77d52c62fa2f82c Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Mon, 20 Jan 2

Re: [PATCH,LRA] Restrict the reuse of spill slots [PR117868]

Vladimir Makarov writes: > On 1/18/25 1:19 AM, Denis Chertykov wrote: >> Vladimir Makarov writes: >> >>> >>> I'd prefer something like the patch in the attachment. >>> >>> It is simpler and even removing more LRA code than adding one. >>> >>> But most important, it generates smaller reserved sta

Re: [PATCH, RFC] Fortran: do not copy back for parameter actual arguments [PR81978]

Hi Paul, Am 20.01.25 um 11:29 schrieb Paul Richard Thomas: Hi Harald, How did we miss that one for so long? This is certainly OK for mainline and, I would suggest, 14-branch. alright, will do that. Thanks for the patch. Thanks for the review! Harald Paul On Sun, 19 Jan 2025 at 20:42,

Re: [PING] [PATCH] testsuite: Fix test failing with -fimplicit-constexpr [PR118277]

Hi Jakub, On 20 Jan 2025, at 10:28, Simon Martin wrote: > Hi Jakub, > > On 20 Jan 2025, at 10:15, Jakub Jelinek wrote: > >> On Mon, Jan 20, 2025 at 08:52:17AM +, Simon Martin wrote: >>> On 12 Jan 2025, at 12:10, Simon Martin wrote: >>> While testing an unrelated C++ patch with "make chec

[PATCH] vect: Preserve OMP info for conditional stores [PR118384]

OMP reductions are lowered into the form: idx = .OMP_SIMD_LANE (simuid, 0); ... oldval = D.anon[idx]; newval = oldval op ...; D.anon[idx] = newval; So if the scalar loop has a {0, +, 1} iv i, idx = i % vf. Despite this wraparound, the vectoriser pretends that the D.anon access

[pushed] aarch64: Fix invalid subregs in xorsign [PR118501]

In the testcase, we try to use xorsign on: (subreg:DF (reg:TI R) 8) i.e. the highpart of the TI. xorsign wants to take a V2DF paradoxical subreg of this, which is rightly rejected as a direct operation. In cases like this, we need to force the highpart into a fresh register first. Tested on

[to-be-committed] [RISC-V] [PR target/116256] Fix latent regression in pattern to associate arithmetic to simplify constants

This is something I spotted working on an outstanding issue with pr116256. It's a latent regression. I'm reasonably sure that with some effort I could find a testcase that would represent a regression, probably just by adjusting the constant index in "f" within in gcc.c-torture/execute/index

Re: [PATCH,LRA] Restrict the reuse of spill slots [PR117868]

On 1/18/25 1:19 AM, Denis Chertykov wrote: Vladimir Makarov writes: I'd prefer something like the patch in the attachment. It is simpler and even removing more LRA code than adding one. But most important, it generates smaller reserved stack space as QI and TI pseudos will share the same

Re: [PATCH] [ifcombine] avoid dropping tree_could_trap_p [PR118514]

On Jan 20, 2025, Richard Biener wrote: > I think this is a bug in tree_could_trap_p which is indeed not considering > out-of-bound accesses of a VAR_DECL (or any decl), but very conservatively > handle ARRAY_REFs. Yeah. I even had a patch to fix it, but it wasn't enough to retain the same trapp

Re: [PATCH]AArch64: Drop ILP32 from default elf multilibs after deprecation

> On 20 Jan 2025, at 19:43, Tamar Christina wrote: > >> -Original Message- >> From: Tamar Christina >> Sent: Friday, January 17, 2025 5:07 PM >> To: Kyrylo Tkachov ; Richard Sandiford >> >> Cc: GCC Patches ; nd ; Richard >> Earnshaw ; ktkac...@gcc.gnu.org >> Subject: RE: [PATCH]AArch6

[committed] d: Fix failing test with 32-bit compiler [PR114434]

Hi, Since the introduction of `gdc.test/runnable/test23514.d', it's exposed an incorrect compilation when adding a 64-bit constant to a link-time address. The current cast to `size_t' causes a loss of precision, which can result in incorrect compilation. Bootstrapped and regtested on x86_64-linu

Re: [PATCH v4] RISC-V: Add a new constraint to ensure that the vl of XTheadVector does not produce a non-zero immediate.

On 1/19/25 4:35 AM, Jin Ma wrote: Although we have handled the vl of XTheadVector correctly in the expand phase and predicates, the results show that the work is still insufficient. In the curr_insn_transform function, the insn is transformed from: (insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:

Re: [PATCH] c++: Only prune capture proxies for constant variables at instantiation time [PR114292]

Hi Jason, On 15 Jan 2025, at 22:42, Jason Merrill wrote: > On 12/12/24 2:07 PM, Simon Martin wrote: >> We currently ICE upon the following valid (under -Wno-vla) code >> >> === cut here === >> void f(int c) { >>constexpr int r = 4; >>[&](auto) { int t[r * c]; }(0); >> } >> === cut here ==

Re: [pushed]PR118067][LRA]: Check secondary memory mode for the reg class

On 1/19/25 2:28 PM, Uros Bizjak wrote: On Fri, Jan 17, 2025 at 10:01 PM Vladimir Makarov wrote: This is one more patch to solve https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067 with different -mcpu used. The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64le

Richard Biener's first COBOL program

> -Original Message- > From: Richard Biener > Sent: Friday, January 10, 2025 02:43 > To: Robert Dubner > Cc: jklow...@symas.com; Joseph Myers ; gcc- > patc...@gcc.gnu.org > Subject: RE: [PATCH] COBOL 3/8 gen: GENERIC interface > > Btw, is recursion allowed? > > f = 1 > fact. > f =

RE: [PATCH]AArch64: Drop ILP32 from default elf multilibs after deprecation

> -Original Message- > From: Tamar Christina > Sent: Friday, January 17, 2025 5:07 PM > To: Kyrylo Tkachov ; Richard Sandiford > > Cc: GCC Patches ; nd ; Richard > Earnshaw ; ktkac...@gcc.gnu.org > Subject: RE: [PATCH]AArch64: Drop ILP32 from default elf multilibs after > deprecation > >

RE: [PATCH] aarch64: Provide initial specifications for Apple CPU cores.

> -Original Message- > From: Iain Sandoe > Sent: Monday, January 20, 2025 6:15 PM > To: Andrew Carlotti > Cc: Kyrylo Tkachov ; GCC Patches patc...@gcc.gnu.org>; Tamar Christina ; Richard > Sandiford ; Sam James > Subject: Re: [PATCH] aarch64: Provide initial specifications for Apple CPU

Re: [PATCH] aarch64: Provide initial specifications for Apple CPU cores.

On Mon, Jan 20, 2025 at 06:29:12PM +, Tamar Christina wrote: > > -Original Message- > > From: Iain Sandoe > > Sent: Monday, January 20, 2025 6:15 PM > > To: Andrew Carlotti > > Cc: Kyrylo Tkachov ; GCC Patches > patc...@gcc.gnu.org>; Tamar Christina ; Richard > > Sandiford ; Sam Jame

Re: [PATCH] RISC-V: Enable and adjust the testsuite for XTheadVector.

On 1/17/25 2:30 AM, Jin Ma wrote: gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/xtheadvector/pr114194.c: Adjust correctly. * gcc.target/riscv/rvv/xtheadvector/prefix.c: Likewise. * gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c: Likewise. * gcc.target/riscv/rvv/

Re: [PATCH] aarch64: Provide initial specifications for Apple CPU cores.

On Mon, Jan 20, 2025 at 06:14:57PM +, Iain Sandoe wrote: > > > > On 20 Jan 2025, at 17:38, Andrew Carlotti wrote: > > > > On Sun, Jan 19, 2025 at 09:14:17PM +, Iain Sandoe wrote: > >> > > >> Please note that the Darwin assembler is Apple’s LLVM backend (invoked via > >> clang -cc1as)

Re: [PATCH] aarch64: Provide initial specifications for Apple CPU cores.

> On 20 Jan 2025, at 17:38, Andrew Carlotti wrote: > > On Sun, Jan 19, 2025 at 09:14:17PM +, Iain Sandoe wrote: >> >> Please note that the Darwin assembler is Apple’s LLVM backend (invoked via >> clang -cc1as) >> and that means that whatever GCC deduces for the feature set and outputs

RE: [PATCH] COBOL 3/8 gen: GENERIC interface

> -Original Message- > From: Richard Biener > Sent: Friday, January 10, 2025 02:43 > To: Robert Dubner > Cc: jklow...@symas.com; Joseph Myers ; gcc- > patc...@gcc.gnu.org > Subject: RE: [PATCH] COBOL 3/8 gen: GENERIC interface > [massive snip. Snip? Nay: amputation!] > > > I _think_

Re: [PATCH] aarch64: Provide initial specifications for Apple CPU cores.

On Sun, Jan 19, 2025 at 09:14:17PM +, Iain Sandoe wrote: > All: > > Thank you all for looking at this - there are a large number of moving parts > and I could > easily be making incorrect assumptions. FWIW the highest weighting in the > inputs I have > are given to DDI0487L_a_a-profile and

Re: [PATCH v2] c++: fix wrong-code with constexpr prvalue opt [PR118396]

On 1/20/25 12:27 PM, Marek Polacek wrote: On Mon, Jan 20, 2025 at 11:46:44AM -0500, Jason Merrill wrote: On 1/20/25 10:27 AM, Marek Polacek wrote: On Fri, Jan 17, 2025 at 06:38:45PM -0500, Jason Merrill wrote: On 1/17/25 1:31 PM, Marek Polacek wrote: On Fri, Jan 17, 2025 at 08:10:24AM -0500,

Re: [PATCH] tree, c++: Consider TARGET_EXPR invariant like SAVE_EXPR [PR118509]

On 1/20/25 4:21 AM, Jakub Jelinek wrote: On Mon, Jan 20, 2025 at 10:14:58AM +0100, Richard Biener wrote: OK (it really makes sense). I do wonder whether there's going to be more fallout similar to the OMP one - did you try grepping for SAVE_EXPR checks? I saw e.g. something for the #pragma om

Re: [PATCH v2] c++: fix wrong-code with constexpr prvalue opt [PR118396]

On Mon, Jan 20, 2025 at 11:46:44AM -0500, Jason Merrill wrote: > On 1/20/25 10:27 AM, Marek Polacek wrote: > > On Fri, Jan 17, 2025 at 06:38:45PM -0500, Jason Merrill wrote: > > > On 1/17/25 1:31 PM, Marek Polacek wrote: > > > > On Fri, Jan 17, 2025 at 08:10:24AM -0500, Jason Merrill wrote: > > > >

vec::reserve semantics (was: [PATCH] c++: Handle RAW_DATA_CST in make_tree_vector_from_ctor [PR118528])

On 1/20/25 5:09 AM, Richard Biener wrote: On Sat, Jan 18, 2025 at 1:02 AM Jason Merrill wrote: I notice that the second argument to vec_safe_reserve is the number of empty spaces to provide, rather than the new desired capacity. So this will allocate space for an additional copy of the whole

[PATCH]middle-end: use ncopies both when registering and reading masks [PR118273]

Hi All, When registering masks for SIMD clone we end up using nmasks instead of nvectors where nmasks seems to compute the number of input masks required for the call given the current simdlen. This is however wrong as vect_record_loop_mask wants to know how many masks you want to create from the

Re: [PATCH] c++/modules: Propagate FNDECL_USED_AUTO alongside deduced return types [PR118049]

On 1/18/25 10:16 PM, Nathaniel Shead wrote: On Fri, Jan 17, 2025 at 11:35:19AM -0500, Patrick Palka wrote: On Fri, 17 Jan 2025, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- In the linked testcase, we're erroring because the declared return

Re: [PATCH] c++, v2: Handle RAW_DATA_CST in make_tree_vector_from_ctor [PR118528]

On 1/18/25 4:04 AM, Jakub Jelinek wrote: On Fri, Jan 17, 2025 at 07:00:33PM -0500, Jason Merrill wrote: --- gcc/c-family/c-common.cc.jj 2025-01-02 11:47:29.803228077 +0100 +++ gcc/c-family/c-common.cc2025-01-17 13:32:53.512294482 +0100 @@ -9016,9 +9016,26 @@ vec * make_tree_vector_from_ct

Re: [PATCH v2] c++: fix wrong-code with constexpr prvalue opt [PR118396]

On 1/20/25 10:27 AM, Marek Polacek wrote: On Fri, Jan 17, 2025 at 06:38:45PM -0500, Jason Merrill wrote: On 1/17/25 1:31 PM, Marek Polacek wrote: On Fri, Jan 17, 2025 at 08:10:24AM -0500, Jason Merrill wrote: On 1/16/25 8:04 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-g

Re: gcc mode switching issue (was Re: RISC-V round_away () handling of non canonical rounding modes)

On 1/18/25 2:41 PM, Palmer Dabbelt wrote: Ya, and thanks for the help.  For anyone else watching, the rest is over here: https://inbox.sourceware.org/libc-alpha/78a20579-2d29-4b3b- af94-434dde755...@rivosinc.com/ (inbox.sourceware.org doesn't seem to handle threading across lists) -- it ce

Re: [PATCH v2] RISC-V: Correct the mode that is causing the program to fail for XTheadCondMov

On 1/19/25 10:56 PM, Jin Ma wrote: For XTheadCondMov, the bit width of rs2 should always be XLEN-sized, otherwise the program logic will be wrong. Reference form https://github.com/XUANTIE-RV/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf Synopsis Move if equal zero

Re: [PATCH] RISC-V: Fix a typo in zce to zcf implication

Hi Robin, Sure, I will do everything you listed shortly, and I will apply a second version of the patch. Regards, Yuriy Kolerov Regards, Yuriy Kolerov From: Robin Dapp Sent: Monday, January 20, 2025 4:02:36 PM To: Yuriy Kolerov ; gcc-patches@gcc.gnu.org Cc: A

Re: [PATCH] libstdc++: perfectly forward std::ranges::clamp arguments

On Mon, 20 Jan 2025, Jonathan Wakely wrote: > > > On Monday, 20 January 2025, Patrick Palka wrote: > > On Sun, 19 Jan 2025, Giuseppe D'Angelo wrote: > > > >> Hi, > >> > >> the attached patch fixes PR118185 (mentioned in the earlier thread about > >> 118160). Tested on x86-64 Linux. > >> > >> Th

Re: [PATCH v2] c++: fix wrong-code with constexpr prvalue opt [PR118396]

On Fri, Jan 17, 2025 at 06:38:45PM -0500, Jason Merrill wrote: > On 1/17/25 1:31 PM, Marek Polacek wrote: > > On Fri, Jan 17, 2025 at 08:10:24AM -0500, Jason Merrill wrote: > > > On 1/16/25 8:04 PM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > >

Re: [PATCH v3] AArch64: Add LUTI ACLE for SVE2

Hey Andrew, On 1/8/2025 12:15 PM, Andrew Carlotti wrote: On Wed, Jan 08, 2025 at 11:13:41AM +, Richard Sandiford wrote: writes: This patch introduces support for LUTI2/LUTI4 ACLE for SVE2. LUTI instructions are used for efficient table lookups with 2-bit or 4-bit indices. LUTI2 reads ind

[PING] [PATCH] c++: Don't ICE in build_class_member_access_expr during error recovery [PR118225]

Hi, On 4 Jan 2025, at 16:13, Simon Martin wrote: > The invalid case in this PR trips on an assertion in > build_class_member_access_expr that build_base_path would never return > an error_mark_node, which is actually incorrect if the object involves > a > tree with an error_mark_node DECL_INITIA

[PING] [PATCH] c++: Reinstate check for uninitialized bases with c++ <= 17 [PR118239]

Hi, On 3 Jan 2025, at 21:00, Simon Martin wrote: > We currently accept this code with c++ <= 17 even though it's invalid > since the base is not initialized (we properly reject it with c++ >= > 20) > > === cut here === > struct NoMut1 { int a, b; }; > struct NoMut3 : NoMut1 { > constexpr NoMut

[PATCH v5] AArch64: Add LUTI ACLE for SVE2

This patch introduces support for LUTI2/LUTI4 ACLE for SVE2. LUTI instructions are used for efficient table lookups with 2-bit or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from the low 128 bits of the table vector using packed 2-bit indices, while LUTI4 can read from the low 128

Re: [PATCH 13/18] s390: arch15: Vector devide/remainder

On Mon, Jan 20, 2025 at 2:59 PM Stefan Schulze Frielinghaus wrote: > > On Mon, Jan 20, 2025 at 02:46:40PM +0100, Richard Biener wrote: > > On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus > > wrote: > > > > > > gcc/ChangeLog: > > > > Interesting - I can't find anything about these in

Re: [PATCH] libstdc++: perfectly forward std::ranges::clamp arguments

On Monday, 20 January 2025, Patrick Palka wrote: > On Sun, 19 Jan 2025, Giuseppe D'Angelo wrote: > >> Hi, >> >> the attached patch fixes PR118185 (mentioned in the earlier thread about >> 118160). Tested on x86-64 Linux. >> >> Thanks, >> -- >> Giuseppe D'Angelo >> > >> Subject: [PATCH] libstdc++:

Re: [PATCH] RISC-V: Fix a typo in zce to zcf implication

> zce must imply zcf but this rule was corrupted after > refactoring in this commit: > > 9e12010b5e724277ea44c300630802f464407d8d > > gcc/ChangeLog: > > * common/config/riscv/riscv-common.cc: fix zce to zcf > implication. Thanks, looks reasonable but please add a test case as it's clea

Re: [PATCH 13/18] s390: arch15: Vector devide/remainder

On Mon, Jan 20, 2025 at 02:46:40PM +0100, Richard Biener wrote: > On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus > wrote: > > > > gcc/ChangeLog: > > Interesting - I can't find anything about these in the PoP (though I can only > find the one from May 2022, 14th edition covering up t

[PATCH] tree-optimization/117875 - missed SLP vectorization

There's a discrepancy in SLP vs non-SLP vectorization that SLP build does not handle plain SSA copies (which should have been elimiated earlier). But this now bites back since non-SLP happily handles them, causing a regression with --param vect-force-slp=1 which is now default, resulting in a big

Re: [PATCH 13/18] s390: arch15: Vector devide/remainder

On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus wrote: > > gcc/ChangeLog: Interesting - I can't find anything about these in the PoP (though I can only find the one from May 2022, 14th edition covering up to z16(?)). Is there a newer document? Richard. > * config/s390/vect

Re: [PATCH] libstdc++: perfectly forward std::ranges::clamp arguments

On Sun, 19 Jan 2025, Giuseppe D'Angelo wrote: > Hi, > > the attached patch fixes PR118185 (mentioned in the earlier thread about > 118160). Tested on x86-64 Linux. > > Thanks, > -- > Giuseppe D'Angelo > > Subject: [PATCH] libstdc++: perfectly forward std::ranges::clamp arguments > > As repor

Re: [pushed] libstdc++: Delete leftover from Profile Mode removal

On Mon, 20 Jan 2025 at 13:02, Jonathan Wakely wrote: > > On Sun, 19 Jan 2025 at 16:19, Gerald Pfeifer wrote: > > > > On Sun, 29 Dec 2024, Jonathan Wakely wrote: > > > On Sun, 29 Dec 2024, 13:55 Gerald Pfeifer wrote: > > >> something tells me this is not the full extent of this issue. Something >

Re: [pushed] libstdc++: Delete leftover from Profile Mode removal

On Sun, 19 Jan 2025 at 16:19, Gerald Pfeifer wrote: > > On Sun, 29 Dec 2024, Jonathan Wakely wrote: > > On Sun, 29 Dec 2024, 13:55 Gerald Pfeifer wrote: > >> something tells me this is not the full extent of this issue. Something > >> to dig into when I find more time. > > I think the explanation

[PATCH] tree-optimization/118552 - failed LC SSA update after unrolling

When unrolling changes nesting relationship of loops we fail to mark blocks as in need to change for LC SSA update. Specifically the LC SSA PHI on a former inner loop exit might be misplaced if that loop becomes a sibling of its outer loop. Bootstrapped and tested on x86_64-unknown-linux-gnu, pus

[PATCH] c++/modules: Handle mismatching TYPE_CANONICAL when deduping partial specs [PR118101]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- In r15-4862 we ensured that merging a partial specialisation would properly update its TYPE_CANONICAL. However, this confuses the deduping mechanism, since the canonical type has updated out from under it, causing is_match

Re: [COMMITTED] Regenerate sparc.opt.urls

> In general you have to remember when adding a new option and/or > documentation for a new option to run make regenerate-opt-urls. But if > you forget and push the change without the opt.urls change a friendly > bot should remind you and even produce a diff that you can use to fix > things up. In

nvptx: Gracefully handle '-mptx=3.1' if neither sm_30 nor sm_35 multilib variant is built (was: nvptx: Support '--with-multilib-list' (was: Raise nvptx code generation to default PTX ISA 7.3, sm_52, t

Hi! On 2024-12-06T12:03:22+0100, I wrote: > Pushed to trunk branch commit 86b3a7532d56f74fcd1c362f2da7f95e8cc4e4a6 > "nvptx: Support '--with-multilib-list'", [...] Pushed to trunk branch commit 6c5937991bd744a4916e9cf65eb5d9c9b5706120 "nvptx: Gracefully handle '-mptx=3.1' if neither sm_30 nor sm_

Re: [PATCH] wwwdocs: Clarify DCO name/identity and (anonymous) pseudonym policy

Hi, On Sun, Jan 19, 2025 at 05:14:20PM +0100, Mark Wielaard wrote: > On Tue, Dec 17, 2024 at 04:40:10PM +0900, Gerald Pfeifer wrote: > > On Mon, 2 Dec 2024, Mark Wielaard wrote: > > > Adjust the DCO text to match the broader community usage and > > > clarifications around the use of real names, kn

Re: [PATCH, RFC] Fortran: do not copy back for parameter actual arguments [PR81978]

Hi Harald, How did we miss that one for so long? This is certainly OK for mainline and, I would suggest, 14-branch. Thanks for the patch. Paul On Sun, 19 Jan 2025 at 20:42, Harald Anlauf wrote: > Dear all, > > this patch addresses a long-standing difference between gfortran and > other brand

Re: [COMMITTED] Regenerate sparc.opt.urls

Hi Eric, On Mon, Jan 20, 2025 at 08:34:22AM +0100, Eric Botcazou wrote: > > sparc added a -mvis3b option, but the sparc.opt.url file wasn't > > regenerated. > > > > Fixes: d309844d6fe0 ("Fix bootstrap failure on SPARC with -O3 > > -mcpu=niagara4") > > Thanks, but how is one supposed to detect th

[PATCH 17/18] s390: Vector shift: Add 128-bit integer support

Add 128-bit vector shift support. Deprecate vector shift by byte builtins where the shift amount is not of type unsigned character. gcc/ChangeLog: * config/s390/s390-builtins.def: Add 128-bit variants. * config/s390/s390-builtin-types.def: Update accordingly. * config/s39

[PATCH 14/18] s390: arch15: Vector compare: Add 128-bit integer support

gcc/ChangeLog: * config/s390/s390-builtins.def: Add 128-bit variants. * config/s390/s390-builtin-types.def: Update accordingly. * config/s390/s390.cc (s390_expand_vec_compare_cc): Also consider TI modes for vectors. * config/s390/vector.md: Enable *vec_cmp e

[PATCH 06/18] s390: arch15: New instruction variants supporting 128-bit integer

Add new instruction variants and also extend builtins in order to deal with 128-bit integer. gcc/ChangeLog: * config/s390/s390-builtins.def: Add new instruction variants. * config/s390/s390-builtin-types.def: Update accordingly. * config/s390/vecintrin.h: Add new defines.

Re: [PATCH] c++: Handle RAW_DATA_CST in make_tree_vector_from_ctor [PR118528]

On Sat, Jan 18, 2025 at 1:02 AM Jason Merrill wrote: > > On 1/17/25 3:08 PM, Jakub Jelinek wrote: > > Hi! > > > > This is the first bug discovered today with the > > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html > > hack but then turned into proper testcases where embed-21.C F

[PATCH 11/18] s390: arch15: Vector generate element masks

Add instruction vgem and vector builtins vec_gen_element_masks_{8,16,32,64,128}. gcc/ChangeLog: * config/s390/s390-builtins.def (s390_vec_gen_element_masks_128): Add. (s390_vgemb): Add. (s390_vgemh): Add. (s390_vgemf): Add. (s390_vgemg): Add. (s390_

[PATCH 07/18] s390: arch15: Load indexed address

Add instructions lxa and llxa. gcc/ChangeLog: * config/s390/s390.md (*lxa_index): Add. (*lxa_displacement_index): Add. (*lxa_index_base): Add. (*lxa_displacement_index_base): Add. (*lxab_displacement_index_base): Add. (*llxa_displacement_index): Add

[PATCH 10/18] s390: arch15: Vector eval

Add instruction veval and builtin vec_evaluate. gcc/ChangeLog: * config/s390/s390-builtins.def (s390_vec_evaluate): Add. (s390_veval): Add. * config/s390/s390-builtin-types.def: Update accordingly. * config/s390/s390.md (UNSPEC_VEC_VEVAL): Add. * config/s39

[PATCH 04/18] s390: Bump __VEC__ and add 128-bit integer zvector types

From: Stefan Schulze Frielinghaus Bump __VEC__ version to 10305 and add 128-bit integer vector types like `vector __int128` et al. to the zvector extension. gcc/ChangeLog: * config/s390/s390-c.cc (rid_int128): New helper function. (s390_macro_to_expand): Deal with `vector __int1

[PATCH 18/18] s390: Update vec_(load,store)_len(,_r)

Reflect latest updates for vec_(load,store)_len(,_r) which means that all types except character based types are deprecated. gcc/ChangeLog: * config/s390/s390-builtins.def (s390_vec_load_len): Deprecate some overloads. (s390_vec_store_len): Deprecate some overloads.

[PATCH 08/18] s390: arch15: Bit deposit and extract

Add instructions bdepg and bextg and corresponding builtins. gcc/ChangeLog: * config/s390/s390-builtins.def (s390_bdepg): Add. (s390_bextg): Add. * config/s390/s390-builtin-types.def: Update accordingly. * config/s390/s390.md (UNSPEC_BDEPG): Add. (UNSPEC_BE

[PATCH 09/18] s390: arch15: Vector blend

Add instruction vblend and builtin vec_blend. gcc/ChangeLog: * config/s390/s390-builtins.def (s390_vec_blend): Add. (s390_vblendb): Add. (s390_vblendh): Add. (s390_vblendf): Add. (s390_vblendg): Add. (s390_vblendq): Add. * config/s390/s390-b

[PATCH 16/18] s390: arch15: Vector maximum/minimum: Add 128-bit integer support

For previous architectures emulate operation max/min. gcc/ChangeLog: * config/s390/s390-builtins.def: Add 128-bit variants and remove bool variants. * config/s390/s390-builtin-types.def: Update accordinly. * config/s390/s390.md: Emulate min/max for GPR. * c

[PATCH 13/18] s390: arch15: Vector devide/remainder

gcc/ChangeLog: * config/s390/vector.md (div3): Add. (udiv3): Add. (mod3): Add. (umod3): Add. gcc/testsuite/ChangeLog: * gcc.target/s390/vxe3/vd-1.c: New test. * gcc.target/s390/vxe3/vd-2.c: New test. * gcc.target/s390/vxe3/vdl-1.c: New test

[PATCH 02/18] s390: Sort definitions in vecintrin.h

From: Stefan Schulze Frielinghaus gcc/ChangeLog: * config/s390/vecintrin.h: Sort definitions. --- gcc/config/s390/vecintrin.h | 229 ++-- 1 file changed, 115 insertions(+), 114 deletions(-) diff --git a/gcc/config/s390/vecintrin.h b/gcc/config/s390/vecin

[PATCH 00/18] s390: arch15: Prepare for a future architecture

This series prepares for a future architecture. Pushed. Stefan Schulze Frielinghaus (18): s390: Stay scalar for TOINTVEC/tointvec s390: Sort definitions in vecintrin.h s390: arch15: Prepare for a future architecture s390: Bump __VEC__ and add 128-bit integer zvector types s390: arch15:

  1   2   >