[PATCH v3 1/3] RISC-V: Add stub support for existing extensions (privileged)

2023-08-28 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v3 2/3] RISC-V: Add stub support for existing extensions (vendor)

2023-08-28 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH v3 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

2023-08-28 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on shar

[PATCH 1/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

2023-08-28 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI As the specification states, the 'Zcmt' extension depends on the 'Zca' and 'Zicsr' extensions. This commit reflects this implication. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add implication from 'Zcmt' to 'Zicsr'. --- gcc/com

[PATCH 0/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

2023-08-28 Thread Tsukasa OI via Gcc-patches
This is a subset of my patch set "RISC-V: Add stub support for existing extensions" for faster review. Since 'Zcmt' requires 'Zicsr' (and this is a bug unlike other changes in the patch set above), this small patch is splitted. T

[PATCH V2] RISC-V: Refactor and clean expand_cond_len_{unop, binop, ternop}

2023-08-28 Thread Lehua Ding
V2 changes: Address the comments from Robin. Hi, This patch refactors the codes of expand_cond_len_{unop,binop,ternop}. Introduces a new unified function expand_cond_len_op to do the main thing. The expand_cond_len_{unop,binop,ternop} functions only care about how to pass the operands to the intr

[PATCH V3] RISC-V: Refactor and clean expand_cond_len_{unop, binop, ternop}

2023-08-28 Thread Lehua Ding
V3 changes: Address the comments from Robin. Hi, This patch refactors the codes of expand_cond_len_{unop,binop,ternop}. Introduces a new unified function expand_cond_len_op to do the main thing. The expand_cond_len_{unop,binop,ternop} functions only care about how to pass the operands to the intr

Re: [PATCH V2] RISC-V: Refactor and clean expand_cond_len_{unop, binop, ternop}

2023-08-28 Thread Lehua Ding
Invalid this patch, please see V3. Sorry for this. On 2023/8/29 11:43, Lehua Ding wrote: V2 changes: Address the comments from Robin. Hi, This patch refactors the codes of expand_cond_len_{unop,binop,ternop}. Introduces a new unified function expand_cond_len_op to do the main thing. The expand

Re: [PATCH] RISC-V: Refactor and clean expand_cond_len_{unop,binop,ternop}

2023-08-28 Thread Lehua Ding
Here is the V3 patch fix the comments, thanks. https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628650.html -- Best, Lehua

[PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

2023-08-28 Thread Eric Feng via Gcc-patches
Hi Dave, Thanks for the feedback. I've addressed the changes you mentioned in addition to adding more test cases. I've also taken this chance to split the test files according to known function subclasses, as you previously suggested. Since there were also some changes to the core analyzer, I've

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

2023-08-28 Thread Eric Feng via Gcc-patches
On Tue, Aug 29, 2023 at 12:32 AM Eric Feng wrote: > > Hi Dave, > > Thanks for the feedback. I've addressed the changes you mentioned in > addition to adding more test cases. I've also taken this chance to > split the test files according to known function subclasses, as you previously > suggested.

Bind RTL to a TREE expr (Re: [Bug target/111166])

2023-08-28 Thread Jiufu Guo via Gcc-patches
Hi All! "rguenth at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66 ... > > > At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so > we can hardly fix it there. Only a later pass could figure each of the > insns fully define the reg. > > Jiu

[PATCH] doc: Add fpatchable-function-entry to Option-Summary page[PR110983]

2023-08-28 Thread Mao via Gcc-patches
The -fpatchable-function-entry is missing in both the web doc [1] and the man page's "Option Summary" section. This patch is to add it. [1]: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html --- gcc/doc/invoke.texi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/d

Re: [pushed] analyzer: fix ICE in text art strings support

2023-08-28 Thread Prathamesh Kulkarni via Gcc-patches
On Fri, 25 Aug 2023 at 18:15, David Malcolm via Gcc-patches wrote: > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > Pushed to trunk as r14-3481-g99a3fcb8ff0bf2. Hi David, It seems the new tests FAIL on arm for LTO bootstrap config: https://ci.linaro.org/job/tcwg_bootstrap_check

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

2023-08-28 Thread Prathamesh Kulkarni via Gcc-patches
On Tue, 15 Aug 2023 at 00:05, Christophe Lyon via Gcc-patches wrote: > > 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. Hi Christophe, It seems your

Re: [wwwdocs] projects/gomp: Update implementation status and minor fixes

2023-08-28 Thread Gerald Pfeifer
On Fri, 25 Aug 2023, Tobias Burnus wrote: > It also fixes a couple of bugs and adds links providing more details > for two items (a PR link as in libgomp.texi and a section in the manual). Nice changes, thanks. +Some are only stubs; see manual (

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

2023-08-28 Thread Christophe Lyon via Gcc-patches
On Tue, 29 Aug 2023 at 08:06, Prathamesh Kulkarni < prathamesh.kulka...@linaro.org> wrote: > On Tue, 15 Aug 2023 at 00:05, Christophe Lyon via Gcc-patches > wrote: > > > > 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

[PATCH] vect test: Remove xfail for riscv

2023-08-28 Thread Juzhe-Zhong
We are planning to enable "vect" testsuite with scalable vector auto-vectorization. This case XPASS: XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1 like ARM SVE. --- gcc/testsuite/gcc.dg/vect/no-scevccp-outer-12.c | 2 +- 1 file changed, 1 insert

Re: Bind RTL to a TREE expr (Re: [Bug target/111166])

2023-08-28 Thread Richard Biener via Gcc-patches
On Tue, 29 Aug 2023, Jiufu Guo wrote: > > Hi All! > > "rguenth at gcc dot gnu.org" writes: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66 > ... > > > > > > At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so > > we can hardly fix it there. Only a later pass co

Re: [PATCH] vect test: Remove xfail for riscv

2023-08-28 Thread Richard Biener via Gcc-patches
On Tue, 29 Aug 2023, Juzhe-Zhong wrote: > We are planning to enable "vect" testsuite with scalable vector > auto-vectorization. > > This case XPASS: > XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect "OUTER > LOOP VECTORIZED." 1 > > like ARM SVE. OK > --- > gcc/testsuite/g

<    1   2