Re: [PATCH v1] RISC-V: Add xfail test case for highpart register overlap of vwcvt

LGTM juzhe.zh...@rivai.ai 於 2024年4月25日 週四 09:26 寫道： > lgtm > > -- > juzhe.zh...@rivai.ai > > > *From:* pan2.li > *Date:* 2024-04-25 09:25 > *To:* gcc-patches > *CC:* juzhe.zhong ; kito.cheng > ; rdapp.gcc ; Pan Li > > *Subject:* [PATCH v1] RISC-V: Add xfail test

RE: [PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt"

Sorry, looks I missed the early clobber which exists before when resolve the conflict manually. File another PATCH for this as below https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649991.html > We probably don't have tests for this, in particular runtime? I am afraid this is true

Re: [PATCH v1] RISC-V: Add xfail test case for highpart register overlap of vwcvt

lgtm juzhe.zh...@rivai.ai From: pan2.li Date: 2024-04-25 09:25 To: gcc-patches CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li Subject: [PATCH v1] RISC-V: Add xfail test case for highpart register overlap of vwcvt From: Pan Li We reverted below patch for register group overlap, add the

[PATCH v1] RISC-V: Add xfail test case for highpart register overlap of vwcvt

From: Pan Li We reverted below patch for register group overlap, add the related insn test and mark it as xfail. And we will remove the xfail after we support the register overlap in GCC-15. bdad036da32 RISC-V: Support highpart register overlap for vwcvt The below test suites are passed for

Re: [PATCH v1] RISC-V: Add early clobber to the dest of vwsll

lgtm juzhe.zh...@rivai.ai From: pan2.li Date: 2024-04-25 09:25 To: gcc-patches CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li Subject: [PATCH v1] RISC-V: Add early clobber to the dest of vwsll From: Pan Li We missed the existing early clobber for the dest operand of vwsll pattern when

[PATCH v1] RISC-V: Add early clobber to the dest of vwsll

From: Pan Li We missed the existing early clobber for the dest operand of vwsll pattern when resolve the conflict of revert register overlap. Thus add it back to the pattern. Unfortunately, we have no test to cover this part and will improve this after GCC-15 open. The below tests are passed

Re: [pushed][PATCH] wwwdocs: gcc-14/changes.html: Add Loongarch changes.

在 2024/4/23 上午11:43, Lulu Cheng 写道: --- htdocs/gcc-14/changes.html | 156 + 1 file changed, 156 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 9509487c..f0f0efe0 100644 --- a/htdocs/gcc-14/changes.html +++

Re: [PATCH] c++, v3: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On 4/24/24 15:47, Jakub Jelinek wrote: On Wed, Apr 24, 2024 at 06:39:33PM -0400, Jason Merrill wrote: --- gcc/cp/decl2.cc.jj 2024-04-23 14:49:41.933186265 +0200 +++ gcc/cp/decl2.cc 2024-04-24 15:17:09.043625729 +0200 @@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl) to

Re: [PATCH v4 2/3] [RFC] ifcvt: Allow more operations in multiple set if conversion

On Tue, 23 Apr 2024, Manolis Tsamis wrote: > diff --git a/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c > b/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c ... > +/* { dg-final { scan-rtl-dump-times "if-conversion succeeded through > noce_convert_multiple_sets" 6

Re: State of risc-v port in the current merge, revert, rinse-repeat commotion

On 4/24/24 12:22, Robin Dapp wrote: > The dynamic icounts looks sane (vs. Apr 10 snapshot) except for a >> regression in x264 which is likely independent of the chaos going on. >> >> Apr 10 | Apr 23  | >>   109f1b28fc94  |  6f0a646dd2fc   | >>

Re: [PATCH] c++, v3: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On Wed, Apr 24, 2024 at 06:39:33PM -0400, Jason Merrill wrote: > > --- gcc/cp/decl2.cc.jj 2024-04-23 14:49:41.933186265 +0200 > > +++ gcc/cp/decl2.cc 2024-04-24 15:17:09.043625729 +0200 > > @@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl) > > to mark the functions at this

Re: [PATCH] c++, v3: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On 4/24/24 09:16, Jakub Jelinek wrote: On Wed, Apr 24, 2024 at 10:16:05AM +0100, Jonathan Wakely wrote: That fixes the testcases too, but seems to regress +FAIL: libstdc++-abi/abi_check There are explicit instantiation definitions that should instantiate those types:

Re: [PATCH] c++: fix source printing for "required from here" message

On Wed, 24 Apr 2024, Jason Merrill wrote: > On 4/24/24 13:22, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, full bootstrap+regtest in progress, > > does this look OK if successful? > > > > -- >8 -- > > > > It seems the diagnostic machinery's source line printing respects > > the

Re: [PATCH] c++: fix source printing for "required from here" message

On 4/24/24 13:22, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, full bootstrap+regtest in progress, does this look OK if successful? -- >8 -- It seems the diagnostic machinery's source line printing respects the pretty printer prefix, but this is undesirable for the call to

[PATCH] c++: fix source printing for "required from here" message

Tested on x86_64-pc-linux-gnu, full bootstrap+regtest in progress, does this look OK if successful? -- >8 -- It seems the diagnostic machinery's source line printing respects the pretty printer prefix, but this is undesirable for the call to diagnostic_show_locus in

Re: [PATCH] c++: print source code in print_instantiation_partial_context_line

On Wed, 24 Apr 2024, Patrick Palka wrote: > On Tue, 9 Apr 2024, Patrick Palka wrote: > > > On Thu, 19 Oct 2023, Patrick Palka wrote: > > > > > On Tue, 3 Oct 2023, David Malcolm wrote: > > > > > > > As mentioned in my Cauldron talk, this patch adds a call to > > > > diagnostic_show_locus to the

Re: [Patch, fortran] PR93678 - [11/12/13/14 Regression] ICE with TRANSFER and typebound procedures

Hi Paul, On 4/24/24 18:26, Paul Richard Thomas wrote: Hi there, This regression turned out to be low hanging fruit, although it has taken four years to reach it :-( The ChangeLog says it all. OK for mainline and backporting after a suitable delay? yes to both. Thanks for "picking" this

Re: State of risc-v port in the current merge, revert, rinse-repeat commotion

Thanks Vineet! > The dynamic icounts looks sane (vs. Apr 10 snapshot) except for a > regression in x264 which is likely independent of the chaos going on. > > Apr 10 | Apr 23  | >   109f1b28fc94  |  6f0a646dd2fc   | > +-+ > 276,584,692,883

Re: [PATCH] c++: print source code in print_instantiation_partial_context_line

On Tue, 9 Apr 2024, Patrick Palka wrote: > On Thu, 19 Oct 2023, Patrick Palka wrote: > > > On Tue, 3 Oct 2023, David Malcolm wrote: > > > > > As mentioned in my Cauldron talk, this patch adds a call to > > > diagnostic_show_locus to the "required from here" messages > > > in

State of risc-v port in the current merge, revert, rinse-repeat commotion

Hi, Per discussion in patchworks call yesterday I gave the trunk snapshot a spin for SPEC2017 build/runs on QEMU (usual flags -Ofast -flto=auto, -march=rv64gcv_zba_zbb_zbs_zicond) 2024-04-23 6f0a646dd2fc Remove repeated information in -ftree-loop-distribute-patterns doc   The dynamic

[Patch, fortran] PR93678 - [11/12/13/14 Regression] ICE with TRANSFER and typebound procedures

Hi there, This regression turned out to be low hanging fruit, although it has taken four years to reach it :-( The ChangeLog says it all. OK for mainline and backporting after a suitable delay? Paul Fortran: Fix ICE in gfc_trans_create_temp_array from bad type [PR93678] 2024-04-24 Paul

[PATCH] c++, v3: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On Wed, Apr 24, 2024 at 10:16:05AM +0100, Jonathan Wakely wrote: > > That fixes the testcases too, but seems to regress > > +FAIL: libstdc++-abi/abi_check > There are explicit instantiation definitions that should instantiate > those types: > > src/c++17/fs_dir.cc:template class

[PATCH] arm: Zero/Sign extends for CMSE security

This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits

RE: [PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt"

> Just noticed, not a problem of the revert but wasn't that wrong before > without the early-clobber? > vwsll.vx v0, v0, a0 for LMUL = 2 would be allowed but should not? > We probably don't have tests for this, in particular runtime? Yes, you are right according to the spec "the overlap is in

Re: [committed] Further spelling fixes in translatable strings

Jakub Jelinek writes: > On Tue, Apr 23, 2024 at 11:32:08AM +0100, Jonathan Wakely wrote: >> On Mon, 22 Apr 2024 at 22:30, Jakub Jelinek wrote: >> Yup: >> https://gcc.gnu.org/codingconventions.html#Spelling >> >> That spelling is explicitly mentioned at the link above, so they >> should be

Re: [PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt"

> (define_insn "@pred_vwsll_scalar" > - [(set (match_operand:VWEXTI 0 "register_operand" "=vd, vr, vd, vr, vd, vr, > vd, vr, vd, vr, vd, vr, ?, ?") > + [(set (match_operand:VWEXTI 0 "register_operand" "=vr, vr") Just noticed, not a problem of the revert but wasn't that wrong before without the

Re: [PATCH] c++/modules testsuite: avoid expensive ggc-min-expand=0

On 4/24/24 05:49, Patrick Palka wrote: On Tue, 23 Apr 2024, Jason Merrill wrote: On 4/23/24 11:28, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? Is the test being run for multiple standard levels? I'd rather restrict it to one and keep fully testing

Re: [PATCH] v2: DOCUMENTATION_ROOT_URL vs. release branches [PR114738]

On Wed, 2024-04-24 at 11:07 +0200, Jakub Jelinek wrote: > On Tue, Apr 23, 2024 at 07:07:17PM -0400, David Malcolm wrote: > > That sounds like a better approach; thanks. > > Attached below.  Tested by checking > ../configure --disable-bootstrap --enable-languages=c --disable- > multilib > built

RE: [PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt"

Committed, thanks Kito. Pan -Original Message- From: Kito Cheng Sent: Wednesday, April 24, 2024 9:11 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; rdapp@gmail.com Subject: Re: [PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt" LGTM,

Re: [PATCH][GCC 13] RISC-V: Fix recursive vsetvli checking [PR114172]

thanks, committed :) On Wed, Apr 24, 2024 at 6:12 PM juzhe.zh...@rivai.ai wrote: > > lgtm. > > > juzhe.zh...@rivai.ai > > > From: Kito Cheng > Date: 2024-04-24 18:09 > To: gcc-patches; kito.cheng; rdapp; juzhe.zhong > CC: Kito Cheng > Subject: [PATCH][GCC 13]

Re: [PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt"

LGTM, thanks Pan, although the revert patch series look a little bit scary, but I believe it's the safest way for now since we don't really fully understand how register filters work, and it's not really good timing to figure out all the detail around that. On Wed, Apr 24, 2024 at 9:02 PM Li,

RE: [PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt"

Request review as this revert patch contains some manually resolved conflict changes. Passed the rv64gcv fully regression test with isl build. Pan -Original Message- From: Li, Pan2 Sent: Wednesday, April 24, 2024 8:59 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai;

[PATCH v1] Revert "RISC-V: Support highpart register overlap for vwcvt"

From: Pan Li This reverts commit bdad036da32f72b84a96070518e7d75c21706dc2. --- gcc/config/riscv/constraints.md | 23 gcc/config/riscv/riscv.md | 24 gcc/config/riscv/vector-crypto.md | 21 ++-- gcc/config/riscv/vector.md

Re: [PATCH] c++/modules testsuite: avoid expensive ggc-min-expand=0

On Tue, 23 Apr 2024, Jason Merrill wrote: > On 4/23/24 11:28, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > Is the test being run for multiple standard levels? I'd rather restrict it to > one and keep fully testing GC-safety. Ah yeah, looks like it

Re: [PATCH v2] gcc-14: Mention that some warnings are now errors

- Am 15. Apr 2024 um 8:05 schrieb Sebastian Huber sebastian.hu...@embedded-brains.de: > --- > v2: Remove listing of options. > > htdocs/gcc-14/changes.html | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index

[COMMITTED BPF] bpf: define BPF feature pre-processor macros

This commit makes the BPF backend to define the following macros for c-family languages: __BPF_CPU_VERSION__ This is a numeric value identifying the version of the BPF "cpu" for which GCC is generating code. __BPF_FEATURE_ALU32 __BPF_FEATURE_JMP32 __BPF_FEATURE_JMP_EXT

Re: [PATCH][GCC 13] RISC-V: Fix recursive vsetvli checking [PR114172]

lgtm. juzhe.zh...@rivai.ai From: Kito Cheng Date: 2024-04-24 18:09 To: gcc-patches; kito.cheng; rdapp; juzhe.zhong CC: Kito Cheng Subject: [PATCH][GCC 13] RISC-V: Fix recursive vsetvli checking [PR114172] extract_single_source will recursive checking the sources to make sure if it's single

[PATCH][GCC 13] RISC-V: Fix recursive vsetvli checking [PR114172]

extract_single_source will recursive checking the sources to make sure if it's single source, however it may cause infinite recursive when the source is come from itself, so it should just skip first source to prevent that. NOTE: This logic has existing on trunk/GCC 14, but it included in a big

[PATCH 2/4] df: Add DF_LIVE_SUBREG problem

This patch add a new DF problem, named DF_LIVE_SUBREG. This problem is extended from the DF_LR problem and support track the subreg liveness of multireg pseudo if these pseudo satisfy the following conditions: 1. the mode size greater than it's REGMODE_NATURAL_SIZE. 2. the reg is used in

[PATCH 4/4] lra: Apply DF_LIVE_SUBREG data

This patch apply the DF_LIVE_SUBREG to LRA pass. More changes were made to the LRA than the IRA since the LRA will modify the DF data directly. The main big changes are centered on the lra-lives.cc file. gcc/ChangeLog: * lra-coalesce.cc (update_live_info): Extend to DF_LIVE_SUBREG.

[PATCH 3/4] ira: Apply DF_LIVE_SUBREG data

This patch simple replace df_get_live_in to df_get_subreg_live_in and replace df_get_live_out to df_get_subreg_live_out. gcc/ChangeLog: * ira-build.cc (create_bb_allocnos): Switch to DF_LIVE_SUBREG df data. (create_loop_allocnos): Ditto. * ira-color.cc

[PATCH 1/4] df: Add -ftrack-subreg-liveness option

Add new flag -ftrack-subreg-liveness to enable track-subreg-liveness. This flag is enabled at -O3/fast. gcc/ChangeLog: * common.opt: add -ftrack-subreg-liveness option. * opts.cc: auto aneble -ftrack-subreg-liveness in -O3/fast --- gcc/common.opt | 4

[PATCH V2 0/4] Add DF_LIVE_SUBREG data and apply to IRA and LRA

Hi Vladimir and Richard, These patches are used to add a new data flow DF_LIVE_SUBREG, which will track subreg liveness and then apply it to IRA and LRA passes (enabled via -O3 or -ftrack-subreg-liveness). These patches are for GCC 15. And these codes are pushed to the devel/subreg-coalesce

Re: [PATCH] c++, v2: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

On Tue, 23 Apr 2024 at 17:05, Jakub Jelinek wrote: > > On Mon, Apr 22, 2024 at 11:14:35PM -0400, Jason Merrill wrote: > > > > The following testcase regressed with Marek's r14-5979 change, > > > > when pr113208_0.C is compiled where the ctor is marked constexpr, > > > > we no longer perform this

[PATCH] v2: DOCUMENTATION_ROOT_URL vs. release branches [PR114738]

On Tue, Apr 23, 2024 at 07:07:17PM -0400, David Malcolm wrote: > That sounds like a better approach; thanks. Attached below. Tested by checking ../configure --disable-bootstrap --enable-languages=c --disable-multilib built trunk on void foo (int x) { __builtin_printf ("%ld\n", x); } testcase

Re: [PATCH] adjust vectorization expectations for ppc costmodel 76b

Hi, on 2024/4/22 17:28, Alexandre Oliva wrote: > Ping? > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566525.html > > > This test expects vectorization at power8+ because strict alignment is > not required for vectors. For power7, vectorization is not to take > place because it's not

[PATCH] tree-optimization/114787 - more careful loop update with CFG cleanup

When CFG cleanup removes a backedge we have to be more careful with loop update. In particular we need to clear niter info and estimates and if we remove the last backedge of a loop we have to also mark it for removal to prevent a following basic block merging to associate loop info with an

RE: [PATCH v1] RISC-V: Add xfail test case for highpart overlap of vext.vf

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Wednesday, April 24, 2024 2:46 PM To: Li, Pan2 ; gcc-patches Cc: kito.cheng ; Robin Dapp ; Li, Pan2 Subject: Re: [PATCH v1] RISC-V: Add xfail test case for highpart overlap of vext.vf LGTM.

Re: [PATCH] i386: Fix behavior for both using AVX10.1-256 in options and function attribute

On Wed, Apr 24, 2024 at 1:46 PM Haochen Jiang wrote: > > Hi all, > > When we are using -mavx10.1-256 in command line and avx10.1-256 in > target attribute together, zmm should never be generated. But current > GCC will generate zmm since it wrongly enables EVEX512 for non-explicitly > set AVX512.

Re: [PATCH v1] RISC-V: Add xfail test case for highpart overlap of vext.vf

LGTM. juzhe.zh...@rivai.ai From: pan2.li Date: 2024-04-24 10:48 To: gcc-patches CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li Subject: [PATCH v1] RISC-V: Add xfail test case for highpart overlap of vext.vf From: Pan Li We reverted below patch for register group overlap, add the related

Re: [Patch, fortran] PR89462 - [11/12/13/14 Regression] gfortran loops in code generation

PS ignore the chunk in trans-array.cc. It is an attempt to fix PR93678 that literally did nothing. Paul On Wed, 24 Apr 2024 at 07:05, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi, > > The linaro pre-commit error testing picked up errors for arm and aarch > since they set the

Re: [Patch, fortran] PR89462 - [11/12/13/14 Regression] gfortran loops in code generation

Hi, The linaro pre-commit error testing picked up errors for arm and aarch since they set the option -pedantic-errors. /home/tcwg-build/workspace/tcwg_gnu_4/abe/snapshots/gcc.git~master/gcc/testsuite/gfortran.dg/pr89462.f90:6:14: Warning: Obsolescent feature: Old-style character length at (1)