Re: FW: [PATCH v1] RISC-V: Support RVV VFWNMACC rounding mode intrinsic API

LGTM juzhe.zh...@rivai.ai From: Li, Pan2 Date: 2023-08-14 15:01 To: juzhe.zh...@rivai.ai Subject: FW: [PATCH v1] RISC-V: Support RVV VFWNMACC rounding mode intrinsic API Kindly ping. Pan -Original Message- From: Li, Pan2 Sent: Monday, August 14, 2023 10:36 AM To: gcc-patches@gcc.

RE: FW: [PATCH v1] RISC-V: Support RVV VFWNMACC rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, August 14, 2023 3:03 PM To: Li, Pan2 Cc: gcc-patches ; kito.cheng Subject: Re: FW: [PATCH v1] RISC-V: Support RVV VFWNMACC rounding mode intrinsic API LGTM juzhe.zh...@rivai.ai

RE: [PATCH v1] RISC-V: Support RVV VFWMSAC rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, August 14, 2023 2:42 PM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFWMSAC rounding mode intrinsic API LGTM juzhe.zh.

Re: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Thanks Richi. CC kewen to see whether this patch is suitable for powerpc and s390. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-08-14 14:53 To: Ju-Zhe Zhong CC: gcc-patches; richard.sandiford Subject: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization On Fri,

RE: [PATCH v1] RISC-V: Support RVV VFWNMSAC rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, August 14, 2023 2:43 PM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFWNMSAC rounding mode intrinsic API LGTM juzhe.zh

Re: [PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout

On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > However, for LoongArch, we do not want such a "toplevel" library > > installation since the default ABI may change. We expect all > > multilib variants of libraries to be instal

[PATCH v1] RISC-V: Support RVV VFSQRT rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFSQRT as the below samples. * __riscv_vfsqrt_v_f32m1_rm * __riscv_vfsqrt_v_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc (class unop_frm): New class fo

Re: [PATCH v1] RISC-V: Support RVV VFSQRT rounding mode intrinsic API

LGTM juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-14 15:39 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFSQRT rounding mode intrinsic API From: Pan Li This patch would like to support the rounding mode API for the VFSQRT as

Re: [PATCHv4, rs6000] Generate mfvsrwz for all subtargets and remove redundant zero extend [PR106769]

Hi Haochen, on 2023/8/14 10:18, HAO CHEN GUI wrote: > Hi, > This patch modifies vsx extract expand and generates mfvsrwz/stxsiwx > for all sub targets when the mode is V4SI and the extracted element is word > 1 from BE order. Also this patch adds a insn pattern for mfvsrwz which > helps eliminat

Re: [PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout

On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote: > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > > > > However, for LoongArch, we do not want such a "toplevel" library > > > installation since the default ABI may change.

Re: [PATCH 2/3] ivopts: Call valid_mem_ref_p with code_helper [PR110248]

On Fri, 2023-06-30 13:46:40 +0800, Kewen.Lin via Gcc-patches wrote: > Bootstrapped and regtested on x86_64-redhat-linux and > powerpc64{,le}-linux-gnu. > > Is it ok for trunk? [...] > diff --git a/gcc/recog.h b/gcc/recog.h > index badf8e3dc1c..c6ef619c5dd 100644 > --- a/gcc/recog.h > +++ b/gcc/

RE: [PATCH v1] RISC-V: Support RVV VFSQRT rounding mode intrinsic API

Committed, thanks Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Monday, August 14, 2023 3:44 PM To: Li, Pan2 ; gcc-patches Cc: Li, Pan2 ; Wang, Yanzhang ; kito.cheng Subject: Re: [PATCH v1] RISC-V: Support RVV VFSQRT rounding mode intrinsic API LGTM juzhe.zh..

[PATCH] Fix print_loop_info ICE

It ICEs when invoked via debug_loops and dump_file clear. Pushed as obvious. * tree-cfg.cc (print_loop_info): Dump to 'file', not 'dump_file'. --- gcc/tree-cfg.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc index ab1f8067c54..fae8

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, Aug 14, 2023 at 01:58:24PM +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: > > * Support options for LoongArch SIMD extensions: > >   new configure options --with-simd={none,lsx,lasx}; > >   new driver options -m[no]-l[a]sx / -msimd={none,lsx,lasx}. > > I sug

Re: [PATCH 2/3] ivopts: Call valid_mem_ref_p with code_helper [PR110248]

Hi, on 2023/8/14 15:53, Jan-Benedict Glaw wrote: > On Fri, 2023-06-30 13:46:40 +0800, Kewen.Lin via Gcc-patches > wrote: >> Bootstrapped and regtested on x86_64-redhat-linux and >> powerpc64{,le}-linux-gnu. >> >> Is it ok for trunk? > [...] > >> diff --git a/gcc/recog.h b/gcc/recog.h >> index b

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, 2023-08-14 at 16:44 +0800, Yujie Yang wrote: > I assume we all want: > >  (1) -mlasx -mlsx -> enable LSX and LASX >  (2) -mlasx -mno-lsx -> disable LSX and LASX >  (3) -mno-lsx -mlasx -> enable LSX and LASX Yes. > Unless we declare -mlsx / -mlasx as driver deferred, AFAIK there is no oth

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Hi Juzhe, on 2023/8/14 15:09, juzhe.zh...@rivai.ai wrote: > Thanks Richi. > > CC kewen to see whether this patch is suitable for powerpc and s390. I did a bootstrapping and regression testing on Power10 (LE) and found a lot of failures. A short list looks like: < FAIL: gcc.c-torture/compile/2

[PATCH] vect: Remove several useless VMAT_INVARIANT checks

Hi, In function vectorizable_load, there is one hunk which is dedicated for the handlings on VMAT_INVARIANT and return early, it means we shouldn't encounter any cases with memory_access_type VMAT_INVARIANT in the following code after that. This patch is to clean up several useless checks on VMAT

[PATCH] vect: Move VMAT_LOAD_STORE_LANES handlings from final loop nest

Hi, Following Richi's suggestion [1], this patch is to move the handlings on VMAT_LOAD_STORE_LANES in the final loop nest of function vectorizable_load to its own loop. Basically it duplicates the final loop nest, clean up some useless set up code for the case of VMAT_LOAD_STORE_LANES, remove som

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, 2023-08-14 at 16:57 +0800, Yujie Yang wrote: > On Mon, Aug 14, 2023 at 04:49:11PM +0800, Xi Ruoyao wrote: > > On Mon, 2023-08-14 at 16:44 +0800, Yujie Yang wrote: > > > I assume we all want: > > > > > >  (1) -mlasx -mlsx -> enable LSX and LASX > > >  (2) -mlasx -mno-lsx -> disable LSX and

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Hi Kewen, > I did a bootstrapping and regression testing on Power10 (LE) and found a lot > of failures. I think the problem is that just like for vec_set we're expecting the vec_extract expander not to fail. It is probably passed not a const int here anymore and therefore fails to expand? can_

[PATCH] vect: Move VMAT_GATHER_SCATTER handlings from final loop nest

Hi, Following Richi's suggestion [1], this patch is to move the handlings on VMAT_GATHER_SCATTER in the final loop nest of function vectorizable_load to its own loop. Basically it duplicates the final loop nest, clean up some useless set up code for the case of VMAT_GATHER_SCATTER, remove some un

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

On Mon, 14 Aug 2023, Robin Dapp wrote: > Hi Kewen, > > > I did a bootstrapping and regression testing on Power10 (LE) and found a > > lot of failures. > > I think the problem is that just like for vec_set we're expecting > the vec_extract expander not to fail. It is probably passed not a > con

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Hi Robin, on 2023/8/14 16:58, Robin Dapp wrote: > Hi Kewen, > >> I did a bootstrapping and regression testing on Power10 (LE) and found a lot >> of failures. > > I think the problem is that just like for vec_set we're expecting > the vec_extract expander not to fail. It is probably passed not

Re: [PATCH v1 2/6] LoongArch: improved target configuration interface

On Mon, Aug 14, 2023 at 04:49:11PM +0800, Xi Ruoyao wrote: > On Mon, 2023-08-14 at 16:44 +0800, Yujie Yang wrote: > > I assume we all want: > > > >  (1) -mlasx -mlsx -> enable LSX and LASX > >  (2) -mlasx -mno-lsx -> disable LSX and LASX > >  (3) -mno-lsx -mlasx -> enable LSX and LASX > > Yes. >

Re: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

- != CODE_FOR_nothing) + != CODE_FOR_nothing + && can_vec_extract_var_idx_p ( + TYPE_MODE (vectype), TYPE_MODE (TREE_TYPE (vectype I think maybe 'can_vec_extract_var_idx_p' check is enough and remove c

Re: [gcc r13-7720] x86: Update model values for Raptorlake.

* Lili Cui via Gcc-cvs: > https://gcc.gnu.org/g:0fa76e35a5f9e141c08fdf151380f2f9689101c7 > > commit r13-7720-g0fa76e35a5f9e141c08fdf151380f2f9689101c7 > Author: Cui, Lili > Date: Mon Aug 14 02:06:00 2023 + > > x86: Update model values for Raptorlake. > > Update model values for

Bootstrap fail on GCC 13 (was: Re: [PATCH] x86: Update model values for Alderlake, Rocketlake and Raptorlake.)

Hi, your GCC 13 commit https://gcc.gnu.org/r13-7720-g0fa76e35a5f9e1 x86: Update model values for Raptorlake. causes a build fail: gcc/common/config/i386/cpuinfo.h: In function ‘const char* get_intel_cpu(__processor_model*, __processor_model2*, unsigned int*)’: gcc/common/config/i386/cpuinfo.h

[PATCH] genrecog: Add SUBREG_BYTE.to_constant check to the genrecog

Hi, there is genrecog issue happens in RISC-V backend. This is the ICE info: 0xfa3ba4 poly_int_pod<2u, unsigned short>::to_constant() const ../../../riscv-gcc/gcc/poly-int.h:504 0x28eaa91 recog_5 ../../../riscv-gcc/gcc/config/riscv/bitmanip.md:314 0x28ec5b4 recog_7 ../../.

[PATCH] Fix for bug libstdc++/110860

The patch below fixes an issue with the fix already committed for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110860 which unfortunately was not sufficient for small magnitude floating point values. With the patch in place, the code now survives the fuzzing I used to find the problem in the f

Re: [PATCH] genrecog: Add SUBREG_BYTE.to_constant check to the genrecog

Juzhe-Zhong writes: > Hi, there is genrecog issue happens in RISC-V backend. > > This is the ICE info: > > 0xfa3ba4 poly_int_pod<2u, unsigned short>::to_constant() const > ../../../riscv-gcc/gcc/poly-int.h:504 > 0x28eaa91 recog_5 > ../../../riscv-gcc/gcc/config/riscv/bitmanip.md:31

Re: [PATCH] rs6000, add overloaded DFP quantize support

Hi Carl, on 2023/8/9 23:52, Carl Love wrote: > > GCC maintainers: > > The following patch adds four built-ins for the decimal floating point > (DFP) quantize instructions on rs6000. The built-ins are for 64-bit > and 128-bit DFP operands. > > The patch also adds a test case for the new builtin

Re: Re: [PATCH] genrecog: Add SUBREG_BYTE.to_constant check to the genrecog

Thanks Richard. It can fix my issue and reverted to the trunk. Thanks. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-08-14 18:00 To: Juzhe-Zhong CC: gcc-patches; rguenther; jeffreyalaw Subject: Re: [PATCH] genrecog: Add SUBREG_BYTE.to_constant check to the genrecog Juzhe-Zhong writ

Re: [PATCH v1 1/6] LoongArch: a symmetric multilib subdir layout

On Mon, 2023-08-14 at 18:18 +0800, Yujie Yang wrote: > On Mon, Aug 14, 2023 at 03:48:53PM +0800, Xi Ruoyao wrote: > > On Mon, 2023-08-14 at 15:37 +0800, Yujie Yang wrote: > > > On Mon, Aug 14, 2023 at 01:38:40PM +0800, Xi Ruoyao wrote: > > > > On Mon, 2023-08-14 at 11:57 +0800, Yang Yujie wrote: >

[PATCH v2] In the pipeline, USE or CLOBBER should delay execution if it starts a new live range.

CLOBBER and USE does not represent real instructions, but in the process of pipeline optimization, they will wait for transmission in ready list like other insns, without considering resource conflicts and cycles. This results in a multi-issue CPU architecture that can be issued at any time if othe

Re: [PATCH] vect: Remove several useless VMAT_INVARIANT checks

On Mon, Aug 14, 2023 at 10:52 AM Kewen.Lin wrote: > > Hi, > > In function vectorizable_load, there is one hunk which is > dedicated for the handlings on VMAT_INVARIANT and return > early, it means we shouldn't encounter any cases with > memory_access_type VMAT_INVARIANT in the following code > aft

Re: [PATCH] vect: Move VMAT_LOAD_STORE_LANES handlings from final loop nest

On Mon, Aug 14, 2023 at 10:54 AM Kewen.Lin wrote: > > Hi, > > Following Richi's suggestion [1], this patch is to move the > handlings on VMAT_LOAD_STORE_LANES in the final loop nest > of function vectorizable_load to its own loop. Basically > it duplicates the final loop nest, clean up some usele

Re: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

On Mon, 14 Aug 2023, juzhe.zh...@rivai.ai wrote: > - != CODE_FOR_nothing) > + != CODE_FOR_nothing > + && can_vec_extract_var_idx_p ( > + TYPE_MODE (vectype), TYPE_MODE (TREE_TYPE > (vectype > > I thin

Re: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Hi, Kewin. Could you test 'can_vec_extract_var_idx_p' and send V5 patch when you pass the testing? Thanks. juzhe.zh...@rivai.ai From: Kewen.Lin Date: 2023-08-14 17:19 To: Robin Dapp CC: gcc-patches; richard.sandiford; rguenther; juzhe.zh...@rivai.ai Subject: Re: [PATCH V4] VECT: Support loop

[PATCH] RISC-V: Support MASK_LEN_{LOAD_LANES,STORE_LANES}

This patch is depending on middle-end support: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627305.html This patch allow us auto-vectorize this following case: #define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \ void __attribute__ ((noinline, noclone))

Re: [PATCH] vect: Move VMAT_GATHER_SCATTER handlings from final loop nest

Thanks for the clean-ups. But... "Kewen.Lin" writes: > Hi, > > Following Richi's suggestion [1], this patch is to move the > handlings on VMAT_GATHER_SCATTER in the final loop nest > of function vectorizable_load to its own loop. Basically > it duplicates the final loop nest, clean up some usel

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Hi Juzhe, on 2023/8/14 20:08, juzhe.zh...@rivai.ai wrote: > Hi, Kewin. > > Could you test 'can_vec_extract_var_idx_p' and send V5 patch when you pass > the testing? The below diff was bootstrapped and regress-tested on Power10 LE. Comparing to the previous v4, the only changes should be the p

[PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API

From: Pan Li This patch would like to support the rounding mode API for the VFREC7 as the below samples. * __riscv_vfrec7_v_f32m1_rm * __riscv_vfrec7_v_f32m1_rm_m Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc (class vfrec7_frm): New class

Re: [PATCH] vect: Move VMAT_LOAD_STORE_LANES handlings from final loop nest

Hi Richi, on 2023/8/14 20:04, Richard Biener wrote: > On Mon, Aug 14, 2023 at 10:54 AM Kewen.Lin wrote: >> >> Hi, >> >> Following Richi's suggestion [1], this patch is to move the >> handlings on VMAT_LOAD_STORE_LANES in the final loop nest >> of function vectorizable_load to its own loop. Basic

RE: [2/2] RISC-V: Constant FP Optimization with 'Zfa'

Hi Tsukasa, What a coincidence, I also implemented zfa extension, which also includes fli related instructions :) links: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627294.html > + if (!TARGET_HARD_FLOAT || !TARGET_ZFA) > +return result; > + switch (GET_MODE (x)) > +{ > +

Re: [RFC] [v2] Extend fold_vec_perm to handle VLA vectors

Prathamesh Kulkarni writes: > On Thu, 10 Aug 2023 at 21:27, Richard Sandiford > wrote: >> >> Prathamesh Kulkarni writes: >> >> static bool >> >> is_simple_vla_size (poly_uint64 size) >> >> { >> >> if (size.is_constant ()) >> >> return false; >> >> for (int i = 1; i < ARRAY_SIZE (size.coe

Re: [PATCH] vect: Move VMAT_GATHER_SCATTER handlings from final loop nest

Hi Richard, on 2023/8/14 20:20, Richard Sandiford wrote: > Thanks for the clean-ups. But... > > "Kewen.Lin" writes: >> Hi, >> >> Following Richi's suggestion [1], this patch is to move the >> handlings on VMAT_GATHER_SCATTER in the final loop nest >> of function vectorizable_load to its own loo

Re: [RFC] GCC Security policy

Hi, Here's the updated draft of the top part of the security policy with all of the recommendations incorporated. Thanks, Sid What is a GCC security bug? === A security bug is one that threatens the security of a system or network, or might compromise the sec

Re: [PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API

I defer this patch's review to kito since I am not sure whether vfrec7 needs rounding mode. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-08-14 20:49 To: gcc-patches CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API

Re: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Thanks Kewen. But I saw there is 2 more files include: +#include "memmodel.h" +#include "optabs.h" Not sure whether Richard and Richi ok with that change ? Thanks. juzhe.zh...@rivai.ai From: Kewen.Lin Date: 2023-08-14 20:45 To: juzhe.zh...@rivai.ai CC: Robin Dapp; richard.sandiford; rguent

[PATCH] tree-optimization/110991 - unroll size estimate after vectorization

The following testcase shows that we are bad at identifying inductions that will be optimized away after vectorizing them because SCEV doesn't handle vectorized defs. The following rolls a simpler identification of SSA cycles covering a PHI and an assignment with a binary operator with a constant

Re: [PATCH] tree-optimization/110991 - unroll size estimate after vectorization

On Mon, 14 Aug 2023, Richard Biener wrote: > The following testcase shows that we are bad at identifying inductions > that will be optimized away after vectorizing them because SCEV doesn't > handle vectorized defs. The following rolls a simpler identification > of SSA cycles covering a PHI and a

Re: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

On Mon, 14 Aug 2023, ??? wrote: > Thanks Kewen. > > But I saw there is 2 more files include: > > +#include "memmodel.h" > +#include "optabs.h" > > Not sure whether Richard and Richi ok with that change ? Yes, please just apply some common sense. > Thanks. > > > > juzhe.zh...@rivai.ai > >

Re: [PATCH] vect: Move VMAT_LOAD_STORE_LANES handlings from final loop nest

On Mon, Aug 14, 2023 at 2:49 PM Kewen.Lin wrote: > > Hi Richi, > > on 2023/8/14 20:04, Richard Biener wrote: > > On Mon, Aug 14, 2023 at 10:54 AM Kewen.Lin wrote: > >> > >> Hi, > >> > >> Following Richi's suggestion [1], this patch is to move the > >> handlings on VMAT_LOAD_STORE_LANES in the fin

Re: [PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API

> +template You don't need a template class here since it can only be UNSPEC_VFREC7. > +class vfrec7_frm : public function_base > +{ > +public: > + bool has_rounding_mode_operand_p () const override { return true; } > + > + rtx expand (function_expander &e) const override > + { > +return e

Re: [PATCH v2 0/3] RISC-V: Support ZC* extensions.

Pushed to the trunk, with slight updates like rename and update testcases :) On Wed, Jun 7, 2023 at 10:28 PM Kito Cheng via Gcc-patches wrote: > > Thanks Jiawei, v2 patch set are LGTM, but I would like to defer this until > binutils part has merged, I know you guys already implement that for a >

[PATCH][GCC] aarch64: Add support for Cortex-A720 CPU

This patch adds support for the Cortex-A720 CPU to GCC. No regressions on aarch64-none-elf. Ok for master? gcc/ChangeLog: * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Cortex- A720 CPU. * config/aarch64/aarch64-tune.md: Regenerate. * doc/invoke.texi: Do

Re: [PATCH] vect: Move VMAT_GATHER_SCATTER handlings from final loop nest

"Kewen.Lin" writes: > Hi Richard, > > on 2023/8/14 20:20, Richard Sandiford wrote: >> Thanks for the clean-ups. But... >> >> "Kewen.Lin" writes: >>> Hi, >>> >>> Following Richi's suggestion [1], this patch is to move the >>> handlings on VMAT_GATHER_SCATTER in the final loop nest >>> of functio

Re: [PATCH] x86: Update model values for Raptorlake.

On 14/08/23 04:37 +, Pan Li via Gcc-patches wrote: Committed as obvious, and backported to GCC13. Did you try building it on gcc-13? case 0x97: case 0x9a: case 0xbf: /* Alder Lake. */ case 0xb7: case 0xba: case 0xbf: /* Raptor Lake. */ This fails: I

Re: [PATCH] x86: Update model values for Raptorlake.

On 14/08/23 15:19 +0100, Jonathan Wakely wrote: On 14/08/23 04:37 +, Pan Li via Gcc-patches wrote: Committed as obvious, and backported to GCC13. Did you try building it on gcc-13? case 0x97: case 0x9a: case 0xbf: /* Alder Lake. */ case 0xb7: case 0xba: case 0xbf:

[PATCH v2] RISC-V: Support RVV VFREC7 rounding mode intrinsic API

From: Pan Li Update in v2: 1. Remove the template of vfrec7 frm class. 2. Update the vfrec7_frm_obj declaration. Original logs: This patch would like to support the rounding mode API for the VFREC7 as the below samples. * __riscv_vfrec7_v_f32m1_rm * __riscv_vfrec7_v_f32m1_rm_m Signed-off-by:

RE: [PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API

Thanks Kito for comments, updated in PATCH v2. https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627367.html Pan -Original Message- From: Kito Cheng Sent: Monday, August 14, 2023 10:07 PM To: 钟居哲 Cc: Li, Pan2 ; gcc-patches ; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Support

Re: [PATCH][RFC] tree-optimization/92335 - Improve sinking heuristics for vectorization

On Mon, 7 Aug 2023 at 13:19, Richard Biener wrote: > > On Mon, Aug 7, 2023 at 2:05 AM Prathamesh Kulkarni via Gcc-patches > wrote: > > > > On Thu, 3 Aug 2023 at 17:48, Richard Biener wrote: > > > > > > On Thu, 3 Aug 2023, Richard Biener wrote: > > > > > > > On Thu, 3 Aug 2023, Richard Biener wro

Re: [PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API

Checked with doc and llvm implementation, LGTM

Re: [PATCH v2 1/2] libstdc++: Implement more maintainable header

Arsen Arsenović writes: > This commit replaces the ad-hoc logic in with an AutoGen > database that (mostly) declaratively generates a version.h bit which > combines all of the FTM logic across all headers together. > > This generated header defines macros of the form __glibcxx_foo, > equivalent

[PATCH v2] analyzer: New option fanalyzer-show-events-in-system-headers [PR110543]

From: benjamin priour Plenty useful, thanks David. I've adjusted some few things, especially the artifacts of earlier versions I missed when building the commit. I didn't how to test for warnings within , I couldn't figure a portable test. I cannot pinpoint the line the warning is issued at in

Avoid division by zero in fold_loop_internal_call

Hi, My patch to fix profile after folding internal call is missing check for the case profile was already zero before if-conversion. Bootstrapped/regtested x86_64-linux, comitted. gcc/ChangeLog: PR gcov-profile/110988 * tree-cfg.cc (fold_loop_internal_call): Avoid division by zer

Re: [PATCH v2] analyzer: New option fanalyzer-show-events-in-system-headers [PR110543]

On Mon, 2023-08-14 at 17:48 +0200, priour...@gmail.com wrote: > From: benjamin priour > > Plenty useful, thanks David. I've adjusted some few things, especially > the artifacts of earlier versions I missed when building the commit. > > I didn't how to test for warnings within , I couldn't figure

Re: [PATCH] tree-optimization/110991 - unroll size estimate after vectorization

> The following testcase shows that we are bad at identifying inductions > that will be optimized away after vectorizing them because SCEV doesn't > handle vectorized defs. The following rolls a simpler identification > of SSA cycles covering a PHI and an assignment with a binary operator > with a

Re: [PATCH] Fix for bug libstdc++/110860

On Mon, 14 Aug 2023 at 10:58, Paul Dreik via Libstdc++ < libstd...@gcc.gnu.org> wrote: > The patch below fixes an issue with the fix already committed for > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110860 which unfortunately > was not sufficient for small magnitude floating point values. > > W

Re: [PATCH v4] Mode-Switching: Fix SET_SRC ICE for create_pre_exit

On 8/12/23 18:56, pan2...@intel.com wrote: From: Pan Li In same cases, like gcc/testsuite/gcc.dg/pr78148.c in RISC-V, there will be only 1 operand when SET_SRC in create_pre_exit. For example as below. (insn 13 9 14 2 (clobber (reg/i:TI 10 a0)) "gcc/testsuite/gcc.dg/pr78148.c":24:1 -1 (

[pushed] c++: -fconcepts and __cpp_concepts

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since -fconcepts no longer implies -fconcepts-ts, we shouldn't advertise TS support with __cpp_concepts=201507L. Also fix one case where -std=c++14 -fconcepts wasn't working (as found by range-v3 calendar). Fixing other cases is not a prio

[PATCH] Fortran: Avoid accessing gfc_charlen when not looking at BT_CHARACTER (PR 110677)

Hello, this patch addresses an issue uncovered by the undefined behavior sanitizer. In function resolve_structure_cons in resolve.cc there is a test starting with: if (cons->expr->ts.type == BT_CHARACTER && comp->ts.u.cl && comp->ts.u.cl->length && comp->ts.u.cl->length

Re: [PATCH v1] c++: follow DR 2386 and update implementation of get_tuple_size [PR110216]

On 8/12/23 04:16, gnaggnoyil wrote: DR 2386 updated the tuple_size requirements for structured binding and it now requires tuple_size to be considered only if std::tuple_size names a complete class type with member value. GCC before this patch does not follow the updated requrements, and this pat

[PATCH] arm: [MVE intrinsics] fix binary_acca_int32 and binary_acca_int64 shapes

Fix these two shapes, where we were failing to check the last non-predicate parameter. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-shapes.cc (binary_acca_int32): Fix loop bound. (binary_acca_int64): Likewise. --- gcc/config/arm/arm-mve-builtins-shape

[PATCH] arm: [MVE intrinsics] Remove dead check for float type in parse_element_type

Fix a likely copy/paste error, where we check if ch == 'f' after we checked it's either 's' or 'u'. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-shapes.cc (parse_element_type): Remove dead check. --- gcc/config/arm/arm-mve-builtins-shapes.cc | 3 +-- 1

Re: [PATCH v3] c++: extend cold, hot attributes to classes

On 8/11/23 09:18, Javier Martinez wrote: Hi Jason, Regarding the initialization example - no, the set of classes that we consider cold is more loosely defined. On Thu, Aug 10, 2023 at 11:01 PM Jason Merrill > wrote: > Yes, but that's because the implicit op== isn't

[PATCH 1/9] arm: [MVE intrinsics] factorize vmullbq vmulltq

Factorize vmullbq, vmulltq so that they use the same parameterized names. 2023-08-14 Christophe Lyon gcc/ * config/arm/iterators.md (mve_insn): Add vmullb, vmullt. (isu): Add VMULLBQ_INT_S, VMULLBQ_INT_U, VMULLTQ_INT_S, VMULLTQ_INT_U. (supf): Add VMULLBQ

[PATCH 2/9] arm: [MVE intrinsics] add unspec_mve_function_exact_insn_vmull

Introduce a function that will be used to build vmull intrinsics with the _int variant. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-functions.h (class unspec_mve_function_exact_insn_vmull): New. --- gcc/config/arm/arm-mve-builtins-functions.h | 74 +++

[PATCH 5/9] arm: [MVE intrinsics] add support for p8 and p16 polynomial types

Although they look like aliases for u8 and u16, we need to define them so that we can handle p8 and p16 suffixes with the general framework. They will be used by vmull[bt]q_poly intrinsics. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins.cc (type_suffixes): Handl

[PATCH 6/9] arm: [MVE intrinsics] add support for U and p formats in parse_element_type

Introduce these two format specifiers to define the shape of vmull[bt]q_poly intrinsics. 'U' is used to define a double-width unsigned 'p' is used to define an element of 'poly' type. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-shapes.cc (parse_element_type):

[PATCH 3/9] arm: [MVE intrinsics] add binary_widen shape

This patch adds the binary_widen shape description. 2023-08-14 Christophe Lyon gcc/: * config/arm/arm-mve-builtins-shapes.cc (binary_widen): New. * config/arm/arm-mve-builtins-shapes.h (binary_widen): New. --- gcc/config/arm/arm-mve-builtins-shapes.cc | 42 +++

[PATCH 7/9] arm: [MVE intrinsics] add binary_widen_poly shape

This patch adds the binary_widen_poly shape description. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-shapes.cc (binary_widen_poly): New. * config/arm/arm-mve-builtins-shapes.h (binary_widen_poly): New. --- gcc/config/arm/arm-mve-builtins-shapes.cc | 4

[PATCH 8/9] arm: [MVE intrinsics] add unspec_mve_function_exact_insn_vmull_poly

Introduce a function that will be used to build vmull[bt]q_poly intrinsics that use poly types. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-functions.h (class unspec_mve_function_exact_insn_vmull_poly): New. --- gcc/config/arm/arm-mve-builtins-functio

[PATCH 4/9] arm: [MVE intrinsics] rework vmullbq_int vmulltq_int

Implement vmullbq_int, vmulltq_int using the new MVE builtins framework. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-base.cc (vmullbq_int, vmulltq_int): New. * config/arm/arm-mve-builtins-base.def (vmullbq_int, vmulltq_int): New.

[PATCH 9/9] arm: [MVE intrinsics] rework vmullbq_poly vmulltq_poly

Implement vmull[bt]q_poly using the new MVE builtins framework. 2023-08-14 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-base.cc (vmullbq_poly) (vmulltq_poly): New. * config/arm/arm-mve-builtins-base.def (vmullbq_poly) (vmulltq_poly): New. *

Re: [pushed]LRA]: Fix asserts for output stack pointer reloads

On Mon, 14 Aug 2023 at 06:39, Vladimir Makarov via Gcc-patches wrote: > > The following patch fixes useless asserts in my latest patch > implementing output stack pointer reloads. Hi Vladimir, It seems that this patch caused the following ICE on aarch64-linux-gnu while building cp-demangle.c: comp

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Hi everyone, I have bootstrapped and regtested the patch below on s390. For the 64-bit target I do not see any changes regarding the testsuite. For the 31-bit target I see the following failures: FAIL: gcc.dg/vect/no-scevccp-outer-14.c (internal compiler error: in require, at machmode.h:313) F

Re: [RFC] GCC Security policy

I think it would help to clarify what the aim of the security policy is. Specifically: (1) What service do we want to provide to users by classifying one thing as a security bug and another thing as not a security bug? (2) What service do we want to provide to the GNU community by the same

Re: [pushed]LRA]: Fix asserts for output stack pointer reloads

On 8/14/23 14:37, Prathamesh Kulkarni wrote: On Mon, 14 Aug 2023 at 06:39, Vladimir Makarov via Gcc-patches wrote: The following patch fixes useless asserts in my latest patch implementing output stack pointer reloads. Hi Vladimir, It seems that this patch caused the following ICE on aarch64

Re: [PATCH] Fortran: Avoid accessing gfc_charlen when not looking at BT_CHARACTER (PR 110677)

Hi Martin, Am 14.08.23 um 19:39 schrieb Martin Jambor: Hello, this patch addresses an issue uncovered by the undefined behavior sanitizer. In function resolve_structure_cons in resolve.cc there is a test starting with: if (cons->expr->ts.type == BT_CHARACTER && comp->ts.u.cl

Re: [RFC] GCC Security policy

On 2023-08-14 14:51, Richard Sandiford wrote: I think it would help to clarify what the aim of the security policy is. Specifically: (1) What service do we want to provide to users by classifying one thing as a security bug and another thing as not a security bug? (2) What service do we wa

Re: [PATCH 0/3] fortran: fix length one character dummy args [PR110419]

Hello, Le 13/08/2023 à 23:16, Harald Anlauf via Fortran a écrit : Hi Mikael, Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches: Hello, (...) I have regression tested this on x86_64-unknown-linux-gnu, and powerpc64-unknown-linux-gnu (both -m32 and -m64). OK for master? this looks

[pushed][LRA]: Process output stack pointer reloads before emitting reload insns

The patch fixes a failure of building aarch64 port with my yesterday patch. The patch was successfully bootstrapped on x86-64 and aarch64. commit c4760c0161f92b92361feba11836e3d066bb330c Author: Vladimir N. Makarov Date: Mon Aug 14 16:06:27 2023 -0400 [LRA]: Process output stack pointer r

Re: [PATCH] RISC-V: Handle no_insn in TARGET_SCHED_VARIABLE_ISSUE.

On 8/11/2023 6:29 AM, Jeff Law via Gcc-patches wrote: On 8/10/23 21:45, Palmer Dabbelt wrote: This seems pretty mechinacial: just scrub through our MDs to check for any un-typed insns, then add the assert and fix the failures.  You're more than welcome to have at it, but LMK if you want

Re: [RFC] GCC Security policy

On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote: > 1. It makes it clear to users of the project the scope in which the project > could be used and what safety it could reasonably expect from the project. In > the context of GCC for example, it cannot expect the compiler to do a safety > check of

Re: [PATCH] Add support for vector conitional not

Andrew Pinski via Gcc-patches writes: > Like the support conditional neg (r12-4470-g20dcda98ed376cb61c74b2c71), > this just adds conditional not too. > Also we should be able to turn `(a ? -1 : 0) ^ b` into a conditional > not. > > OK? Bootstrapped and tested on x86_64-linux-gnu and aarch64-linux-

Re: [PATCH v4 2/8] libcpp: diagnostics: Support generated data in expanded locations

On Fri, Aug 11, 2023 at 07:02:49PM -0400, David Malcolm wrote: > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote: > > The previous patch in this series introduced the concept of LC_GEN line > > maps. This patch continues on the path to using them to improve _Pragma > > diagnostics, by adding a

Re: [RFC] GCC Security policy

On 2023-08-14 17:16, Alexander Monakov wrote: On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote: 1. It makes it clear to users of the project the scope in which the project could be used and what safety it could reasonably expect from the project. In the context of GCC for example, it cannot expe

Re: [PATCH] Add support for vector conitional not

On Mon, Aug 14, 2023 at 2:37 PM Richard Sandiford via Gcc-patches wrote: > > Andrew Pinski via Gcc-patches writes: > > Like the support conditional neg (r12-4470-g20dcda98ed376cb61c74b2c71), > > this just adds conditional not too. > > Also we should be able to turn `(a ? -1 : 0) ^ b` into a condi

  1   2   >