LGTM :)
On Thu, Jul 10, 2025 at 6:00 PM Robin Dapp wrote:
>
> Hi,
>
> Changes from v1:
> - Use Himode broadcast instead of float broadcast, saving two conversion
>insns.
>
> Let's be daring and leave the thorough testing to the CI first while my own
> testing is in progress :)
>
> This patch
On Thu, Jul 10, 2025 at 5:31 PM Robin Dapp wrote:
>
> >> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
> >> index 6753b01db59..866aaf1e8a0 100644
> >> --- a/gcc/config/riscv/vector.md
> >> +++ b/gcc/config/riscv/vector.md
> >> @@ -1580,8 +1580,27 @@ (define_insn_and_split "*
OK to trunk, although I didn't build a RISC-V rtems toolchain, but I
believe you have verified that change :)
On Thu, Jul 10, 2025 at 1:55 PM Sebastian Huber
wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/t-rtems: Add -mstrict-align multilibs for
> targets without support for misali
> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
> index 6753b01db59..866aaf1e8a0 100644
> --- a/gcc/config/riscv/vector.md
> +++ b/gcc/config/riscv/vector.md
> @@ -1580,8 +1580,27 @@ (define_insn_and_split "*vec_duplicate"
>"&& 1"
>[(const_int 0)]
>{
> -riscv_
OK if Pan say OK
On Wed, Jul 9, 2025 at 4:36 PM Ciyan Pan wrote:
>
> From: panciyan
>
> This patch adjust test data for unsigned vector SAT_SUB to vec_sat_data.h
>
> Passed the rv64gcv regression test.
>
> Signed-off-by: Ciyan Pan
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/au
OK :)
On Wed, Jul 2, 2025 at 12:22 PM Dimitar Dimitrov wrote:
>
> Some test cases explicitly set -march or -mcpu with extensions which
> are not compatible with the E ABI variants. This leads to spurious
> errors when toolchain has been configured for RV32E base ISA and
> ILP32E ABI:
> cc1: er
This commit introduces a primary vector pipeline model for the SiFive 7
series, that pipeline model is kind of simplified version, it only
defined vector command queue, arithmetic unit, and vector load store
unit.
The latency of real hardware is LMUL-aware, but I realize that will
complicate the m
gcc/ChangeLog:
PR target/120659
* config/riscv/sifive-7.md: Add B extension, fp16 and missing
scalar instruction type for sifive-7 pipeline model.
gcc/testsuite/ChangeLog:
PR target/120659
* gcc.target/riscv/pr120659.c: New test.
---
gcc/config/riscv/sifi
Most testcase in rvv folder already ignore -Oz, but some of them
are not. This patch makes them consistent.
gcc/testsuite/ChangeLog.
* gcc.target/riscv/rvv/vsetvl/avl_single-21.c: Ignore -Oz.
* gcc.target/riscv/rvv/vsetvl/avl_single-26.c: Ditto.
* gcc.target/riscv/rvv/vset
I found that isn't included in this patch after I committed that...I try to
fix that soon but CI caught me :P
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c67f7f8d4c8aadbe8efd733c29d13bfcbb0f50f
On Thu, Jun 26, 2025 at 10:05 PM Robin Dapp wrote:
> Hi Kito,
>
> > This patch adds a comment to t
This patch adds a comment to the riscv.md file to clarify the purpose of
the file and reorders the include files for better organization.
gcc/ChangeLog:
* config/riscv/riscv.md: Add comment and reorder include
files.
---
gcc/config/riscv/riscv.md | 19 +++
1 file
Pipeline checker utility for RISC-V architecture that validates processor
pipeline models. This tool analyzes machine description files to ensure all
instruction types are properly handled by pipeline scheduling models.
I write this tool since I am implment vector pipeline stuff for SiFive
core, b
> Use pr115763-2.c as example:
>
> ; w/o this patch, one vec load
> fsh fa0,14(sp)
> addi a5,sp,14
> vsetivli zero,2,e16,mf4,ta,ma
> vlse16.v v1,0(a5),zero
>
> vs
>
> ; w/ this patch, two vector instruction
> fcvt.s.hfa0,fa0
> vsetivlizero,2,e32,mf2,ta,ma
> vfmv.v.fv1,fa0
>
> >> -riscv_vector::emit_vlmax_insn (code_for_pred_broadcast (mode),
> >> - riscv_vector::UNARY_OP, operands);
> >> +/* We cannot do anything with a Float16 mode apart from converting.
> >> + So convert to float, broadcast and truncate. */
> >> +
> -riscv_vector::emit_vlmax_insn (code_for_pred_broadcast (mode),
> - riscv_vector::UNARY_OP, operands);
> +/* We cannot do anything with a Float16 mode apart from converting.
> + So convert to float, broadcast and truncate. */
> +if (TARGET_ZVFH
> +++ b/gcc/config/riscv/andes.md
> @@ -0,0 +1,430 @@
> +;; Machine description for Andes vendor extensions
> +;; Copyright (C) 2021-2025 Free Software Foundation, Inc.
2025 rather than 2021-2025
>+(define_constraint "ads_Bz07"
Could you rename it to Ou07?
>+ "Zero extended immediate 7-bit v
It's really great to see the GCC part finally sent out after so many
years since I left the Andes :)
Just one minor comment:
> +++ b/gcc/config/riscv/riscv-ext-andes.def
> @@ -0,0 +1,100 @@
> +/* Ventana extension definition file for RISC-V.
It should be Andes :P
I guess we should implement an auto generated document for mcpu and
mtune document like what we do for -march.
Dongyan, do you have interest to implement that? :)
On Thu, Jun 19, 2025 at 10:02 PM Jeff Law wrote:
>
>
>
> On 6/19/25 1:55 AM, Kito Cheng wrote:
> > Thanks, pus
LGTM
On Thu, Jun 19, 2025 at 6:27 PM wrote:
>
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vminu.vv
> into vminu.vx on the cost value of GR2VR. The late-combine will take
> place if the cost of GR2VR is zero, or reject the combine if non-zero
> like 1, 2, 15 in
Thanks, pushed with one minor change.
Robin has mentioned that maybe we could name it generic-in-order, but
I think this could be a follow up patch if we want, I would like to
have -mtune=generic even though we added that since clang/LLVM already
provided -mtune=generic :)
> diff --git
> a/gcc/t
Hi YunZe:
Generally I am open minded to accept vendor extensions, however this
patch set really introduces too much pattern...
- NUM_INSN_CODES (defined in insn-codes.h) become 83625 from 48573. (+72%)
- Total line of insn-emit-*.cc becomes 1749362 from 1055750. (+65%)
- Total line of insn-recog
> @@ -78,6 +79,7 @@ RISCV_CORE("sifive-e31", "rv32imac",
> "sifive-3-series")
> RISCV_CORE("sifive-e34", "rv32imafc", "sifive-3-series")
> RISCV_CORE("sifive-e76", "rv32imafc", "sifive-7-series")
>
> +RISCV_CORE("generic", "rv64gc","generic")
^^^ Drop this and add
Maybe it's a good time to create a -mtune=generic and copy-and-modify
from rocket?
On Wed, Jun 18, 2025 at 6:59 AM Jeff Law wrote:
>
>
>
> On 6/17/25 10:51 AM, Yangyu Chen wrote:
> >
> >
> > On 17/6/2025 20:42, Jeff Law wrote:
> >>
> >>
> >> On 6/16/25 10:08 PM, Dongyan Chen wrote:
> >>> Hi, I've
Motivation of this patch is we want to use ld/sd if possible when zilsd
is enabled, however the subreg pass may split that into two lw/sw
instructions because the cost, and it only check cost for 64 bits reg move,
that's why we need adjust cost for 64 bit reg move as well.
However even we adjust t
Use riscv_v_ext_mode_p to check the mode size is 2x XLEN, instead of
using "(GET_MODE_UNIT_SIZE (mode) == (UNITS_PER_WORD * 2))".
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_move): Use
riscv_2x_xlen_mode_p.
(riscv_binary_cost): Ditto.
(riscv_hard_regno
LGTM
On Tue, Jun 17, 2025 at 10:14 AM wrote:
>
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vmin.vv
> into vmin.vx on the cost value of GR2VR. The late-combine will take
> place if the cost of GR2VR is zero, or reject the combine if non-zero
> like 1, 2, 15 in
PIE may cause some code gen difference in the testcases, that will cause
problem when we configure toolchain with `--enable-default-pie`.
So adding -fno-pie flags to the testcases to avoid this issue.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/jump-table-large-code-model.c: Adding
LGTM
於 2025年6月14日 週六 22:38 寫道：
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vmaxu.vv
> into vmaxu.vx on the cost value of GR2VR. The late-combine will take
> place if the cost of GR2VR is zero, or reject the combine if non-zero
> like 1, 2, 15 in test. There
Thanks, pushed to trunk :)
On Fri, Jun 13, 2025 at 4:18 AM Joseph Myers wrote:
>
> On Tue, 10 Jun 2025, Kito Cheng wrote:
>
> > GCC will try to read the spec file from the directory where it is
> > installed, but it should try to read from gcc_exec_prefix rather than
>
LGTM, but I would like to make sure either Jeff or Patrick is OK too :)
On Wed, Jun 11, 2025 at 4:48 PM Umesh Kalappa wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/sync.md (lrsc_atomic_exchange):
> Use the scratch reg for rd.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/r
GCC will try to read the spec file from the directory where it is
installed, but it should try to read from gcc_exec_prefix rather than
standard_exec_prefix, because the latter is not the right one if
compiler has been relocated into other places other than the path
specfied at configuration time.
Regenerates the `riscv-ext.texi` file in the GCC documentation.
gcc/ChangeLog:
* doc/riscv-ext.texi: Regen.
---
gcc/doc/riscv-ext.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/riscv-ext.texi b/gcc/doc/riscv-ext.texi
index e69a2df768d..c3ed1bfb593 100644
Oh, yeah, I got your point, I was just misreading, the march is
rv32imac rather than rv32imafc, that is because of the complicated
implication rule.
So I think maybe we should mark C-ext as a EXT_FLAG_MACRO
Then skip all EXT_FLAG_MACRO during riscv_subset_list::match_score?
something like that:
I got compilation issue for this patch:
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/config/riscv/thead-vector-builtins-bases.cc
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/config/riscv/thead-vector-builtins-bases.cc:
In member function ‘rtx_def* riscv_vector::th_vlseg::exp
and(riscv_v
> diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
> index de23e410d4c..b78e2762cfa 100644
> --- a/gcc/config/riscv/thead.cc
> +++ b/gcc/config/riscv/thead.cc
> @@ -1059,12 +1059,17 @@ th_asm_output_opcode (FILE *asm_out_file, const char
> *p)
> get_attr_type (current_o
Hi Yunze:
I thought the T-head vector should just reuse segments load/store
pattern from standard vector instruction is enough and then adjust the
output name at th_asm_output_opcode , do you have a good reason why we
need to add those patterns for T-head vector again? I am really
concerned about
On Wed, May 28, 2025 at 8:03 PM yunzezhu wrote:
>
> > I thought this issue should be fixed when we implement those
> > implication rules correctly? Does march=rv32imaf_zca/mabi=ilp32 still
> > not able select march=rv32imac/mabi=ilp32 still happen after this[1]
> > patch?
> >
> > [1]
> > https://
LGTM
On Fri, Jun 6, 2025 at 3:06 PM wrote:
>
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vdivu.vv into
> vdivu.vx on the cost value of GR2VR. The late-combine will take place if
> the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15
> in tes
pushed
On Thu, Jun 5, 2025 at 3:25 PM Kito Cheng wrote:
>
> It's new C++ language feature introduced in C++17, which is higher than
> the build environment required by the GCC (C++14).
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc: Remove structu
Hi MaskRay,
I was thinking that since GCC is still in the development stage, it
would be fine to accept the change now and adjust it later, because
the release processes for GCC and LLVM are quite different.
I've always preferred having a consistent user interface between the
GNU toolchain and LL
It's new C++ language feature introduced in C++17, which is higher than
the build environment required by the GCC (C++14).
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Remove structured binding
from the code.
---
gcc/common/config/riscv/riscv-common.cc | 27 +
LGTM :)
On Thu, Jun 5, 2025 at 2:21 PM Jiawei wrote:
>
> These patches add support for several privileged RISC-V extensions, including
> Sm/scsrind, Smrnmi, Ssccptr, Sscounterenw, Sstvala, Sstvecd, and Ssu64xl.
>
> The CSRs definition in Binutils part, and gcc part just let the compiler and
> use
LGTM
於 2025年6月4日 週三，11:23寫道：
> From: Pan Li
>
> Some similar code could be wrapped to func get_vector_binary_rtx_cost,
> thus leverage this function to avoid code duplication.
>
> The below test suites are passed for this patch series.
> * The rv64gcv fully regression test.
>
> gcc/ChangeLog:
>
I am a little hesitant about whether to let -march implicitly set
-mtune, because this is equivalent to making -march become another
-mcpu with higher priority, and we cannot avoid discussing the
priority of -march and -mtune again, and no matter what the priority
is, it will introduce more complic
LGTM, and will commit once CI happy, BTW, next time you could name the
testcase into arch-.c e.g. arch-svbare.c, that could prevent
potential filename conflict. :)
On Tue, Jun 3, 2025 at 9:22 AM Dongyan Chen
wrote:
>
> This patch support svbare extension, which is an extension in RVA23 profile.
>
CI passed, pushed to trunk :)
On Thu, May 29, 2025 at 1:59 PM Kito Cheng wrote:
>
> This commit implements a full-featured iterator for the
> riscv_subset_list, that it able to use range-based-for-loop.
>
> That could simplfy the code in the future, and make it more readab
Pushed to trunk :)
On Fri, May 30, 2025 at 2:01 PM Richard Biener
wrote:
>
> On Thu, May 29, 2025 at 8:06 AM Kito Cheng wrote:
> >
> > `--enable-default-pie` is an option to specify whether to enable
> > position-independent executables by default for `target`.
> >
committed :)
On Mon, Jun 2, 2025 at 11:28 AM Jeff Law wrote:
>
>
>
> On 5/28/25 11:59 PM, Kito Cheng wrote:
> > Separate the build rules to compile and link stage to make sure
> > BUILD_LINKERFLAGS and BUILD_LDFLAGS are applied correctly.
> >
> > We hit this
pushed to trunk :)
On Thu, May 29, 2025 at 1:19 PM Jiawei wrote:
>
> Add support of double trap extension [1], enabling GCC
> to recognize the following extensions at compile time.
>
> New extensions:
> - ssdbltrp
> - smdbltrp
>
> [1]
> https://github.com/riscv/riscv-double-trap/releases
`--enable-default-pie` is an option to specify whether to enable
position-independent executables by default for `target`.
However c++tools is build for `host`, so it should just follow
`--enable-host-pie` option to determine whether to build with
position-independent executables or not.
NOTE:
I
Separate the build rules to compile and link stage to make sure
BUILD_LINKERFLAGS and BUILD_LDFLAGS are applied correctly.
We hit this issue when we try to build GCC with non-system-default g++,
and it use newer libstdc++, and then got error from using older libstdc++ from
system, that should not
This commit implements a full-featured iterator for the
riscv_subset_list, that it able to use range-based-for-loop.
That could simplfy the code in the future, and make it more readable,
also more compatible with standard C++ containers.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_cp
I thought this issue should be fixed when we implement those
implication rules correctly? Does march=rv32imaf_zca/mabi=ilp32 still
not able select march=rv32imac/mabi=ilp32 still happen after this[1]
patch?
[1]
https://github.com/gcc-mirror/gcc/commit/42ce61eaefc4db70e2e7ea2d8ef091daa458eb48
On
Pushed to trunk :)
On Wed, May 21, 2025 at 2:35 AM Jeff Law wrote:
>
>
>
> On 5/19/25 12:48 AM, Kito Cheng wrote:
> > Hi Jin:
> >
> > Thanks for heads up:)
> >
> > Hi Jeff:
> >
> > I've rebased that on the trunk and everything seems righ
On Wed, May 21, 2025 at 10:19 PM Robin Dapp wrote:
>
> > I could imagine that is a simpler way to set the march since the march
> > string becomes terribly long - we have an arch string more than 300
> > char...so I support this, although I think this should be discuss with
> > LLVM community, but
Could you make a simple testcase that could vectorize two loops in
different modes (e.g one SI and one SF) and with this param will only
auto vec on loop?
On Wed, May 21, 2025 at 9:47 PM Robin Dapp wrote:
>
> Hi,
>
> This patch adds a --param=autovec-mode=. When the param is
> specified we make
I could imagine that is a simpler way to set the march since the march
string becomes terribly long - we have an arch string more than 300
char...so I support this, although I think this should be discuss with
LLVM community, but I think it's fine to accept as a GCC extension.
So LGTM, go ahead to
LGTM
On Wed, May 21, 2025 at 9:49 PM Robin Dapp wrote:
>
> Hi,
>
> this patch initializes saved_vxrm_mode to VXRM_MODE_NONE. This is a
> warning (but no error) when building the compiler so better fix it.
>
> Regtested on rv64gcv_zvl512b. Going to commit as obvious if the CI
> is happy.
>
> Reg
Committed to trunk, thanks :)
On Mon, May 19, 2025 at 10:44 AM Songhe Zhu
wrote:
>
> From: zhusonghe
>
> The variables `major` and `minor` in `gen-riscv-ext-texi.cc`
> conflict with the macros of the same name defined in ``,
> which are exposed when building with newer versions of GCC on older
>
Pushed to trunk :)
On Mon, May 19, 2025 at 3:18 PM Dongyan Chen
wrote:
>
> During the GCC compilation, some warnings about temporary object dangling
> references emerged. They appeared in these code lines in riscv-common.cc:
> const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext
committed to trunk :)
On Mon, May 19, 2025 at 11:49 AM Kito Cheng wrote:
> On Sat, May 17, 2025 at 9:34 PM Jeff Law wrote:
> >
> >
> >
> > On 5/14/25 9:14 PM, Kito Cheng wrote:
> > > This commit adds the code gen support for Zilsd, which is a
> > >
Hi Jin:
Thanks for heads up:)
Hi Jeff:
I've rebased that on the trunk and everything seems right, do you think
it's OK for the trunk?
On Mon, May 19, 2025 at 2:35 PM Jin Ma wrote:
> On Sun, 16 Mar 2025 11:23:07 -0600, Jeff Law wrote:
> >
> >
> > On 3/
Seems like you don't really add new intrinsics for those two new
extensions? Also our policy is only to add extensions when they are
ratified.
I am happy to review the patch anyway, but just remind you we won't
accept that until it is ratified :)
On Mon, Apr 14, 2025 at 4:25 PM Dongyan Chen
wrot
On Sat, May 17, 2025 at 9:34 PM Jeff Law wrote:
>
>
>
> On 5/14/25 9:14 PM, Kito Cheng wrote:
> > This commit adds the code gen support for Zilsd, which is a
> > newly added extension for RISC-V. The Zilsd extension allows
> > for loading and storing 64-bit
Committed :)
On Sat, May 17, 2025 at 9:36 PM Jeff Law wrote:
>
>
>
> On 5/14/25 9:20 PM, Kito Cheng wrote:
> > This commit introduces a new operand constraint `cR` for the RISC-V
> > architecture, which allows the use of an even-odd RVC general purpose
> > regis
I am surprised that such generic names are defined within the system
header files, I inclined just rename that to major_version,
minor_version, could you send a patch for that?
On Fri, May 16, 2025 at 3:50 PM Songhe Zhu wrote:
>
> Hi kito
> When syncing GCC to the master branch and building
Hm, it really doesn't make too much sense to get that warning, but
I can reproduce that when I compile with gcc 13 (and newer)...and
seems like a known issue [1][2]...
However I don't really like that approach, could you change the
argument type of get_riscv_ext_info to `const char *` to suppr
This commit introduces a new operand constraint `cR` for the RISC-V
architecture, which allows the use of an even-odd RVC general purpose register
(x8-x15) in inline asm.
Ref: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/102
gcc/ChangeLog:
* config/riscv/constraints.md (cR): New
This commit adds the code gen support for Zilsd, which is a
newly added extension for RISC-V. The Zilsd extension allows
for loading and storing 64-bit values using even-odd register
pairs.
We only try to do miminal code gen support for that, which means only
use the new instructions when the load
pushed :)
On Wed, May 14, 2025 at 9:18 PM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> On Tue, May 13, 2025 at 4:34 AM Kito Cheng wrote:
> >
> > We forgot to initialize m_allow_adding_dup in the constructor of
> > riscv_subset_list, then that will be a ra
Pushed, thanks :)
On Tue, May 13, 2025 at 3:25 PM Jiawei wrote:
>
> The augmented hypervisor series extensions 'sha'[1] is a new profile-defined
> extension series that captures the full set of features that are mandated to
> be supported along with the 'H' extension.
>
> [1]
> https://github.c
gcc/ChangeLog:
* config/riscv/riscv-ext.opt.urls: Regenerate.
---
gcc/config/riscv/riscv-ext.opt.urls | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/riscv/riscv-ext.opt.urls
b/gcc/config/riscv/riscv-ext.opt.urls
index e69de29bb2d..c4f471079df 100644
--- a/gcc/config/ris
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683671.html
On Wed, May 14, 2025 at 6:58 PM Mark Wielaard wrote:
>
> Hi Kito,
>
> On Mon, May 12, 2025 at 10:17:36PM +0800, Kito Cheng wrote:
> > Leverage the centralized riscv-ext.def definitions to auto-generate
> >
gcc/ChangeLog:
* config/riscv/t-riscv: Drop duplicate build rule for
riscv-ext.opt.
---
gcc/config/riscv/t-riscv | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/riscv/t-riscv b/gcc/config/riscv/t-riscv
index e99d6689ba0..854daa96e73 100644
--- a/gcc/config/riscv/t-
Hehe, you are late a little bit, let rewrite this with riscv-ext.def
On Tue, May 13, 2025 at 11:56 AM Jiawei wrote:
>
> The augmented hypervisor series extensions 'sha'[1] is a new profile-defined
> extension series that captures the full set of features that are mandated to
> be supported along
pushed
On Mon, May 12, 2025 at 10:18 PM Kito Cheng wrote:
>
> I guess this patch set is not interesting to most people, so I will commit
> that once CI green :P
>
> On Mon, May 12, 2025 at 10:17 PM Kito Cheng wrote:
>>
>> Adding a new ISA extension to RISC-V GCC
We forgot to initialize m_allow_adding_dup in the constructor of
riscv_subset_list, then that will be a random value...that will lead
to a random behavior of the -march may accpet duplicate extension.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::riscv_s
Refactor extension flag handling by removing the old riscv_ext_flag_table and
sourcing all flag definitions directly from the flags field of the unified
riscv_ext_info_t structures generated from riscv-ext.def.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_extra_ext_flag_tab
Consolidate implied-extension logic by removing the old `riscv_implied_info`
array and using the `implied_exts` field in the unified riscv_ext_info_t
structures generated from `riscv-ext.def`.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_implied_info::riscv_implied_
Define a new riscv_ext_info_t struct to aggregate all ISA extension fields
(name, version, flags, implied extensions, bitmask and extra flags) generated
from riscv-ext.def.
Also adjust riscv_ext_flag_table_t and riscv_implied_info_t to make it
able to not hold extension name, this part will refact
Leverage the centralized riscv-ext.def definitions to auto-generate
the target option parsing and associated internal flags, replacing
manual listings in riscv.opt; `riscv_ext_flag_table` part will remove in
later patch.
gcc/ChangeLog:
* config/riscv/gen-riscv-ext-opt.cc: New.
* c
Automatically build the ISA extension reference table in invoke.texi from
the unified riscv-ext.def metadata, ensuring documentation stays in sync
with extension definitions and reducing manual maintenance.
gcc/ChangeLog:
* doc/invoke.texi: Replace hand‑written extension table with
We don't hold any extenison flags in `target_flags`, so no need to
gather the extenison flags in `target_flags`.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_can_inline_p): Drop
extension flags check from `target_flags`.
* config/riscv/riscv-subset.h (riscv_
This commit drops the riscv_ext_version_table and instead uses the
riscv_ext_info_t data structure to provide the version information
for RISC-V extensions.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_ext_version_table):
Remove.
(standard_extensions_p): Use
Adding a new ISA extension to RISC-V GCC requires modifying several places:
1. riscv_ext_version_table for the extension version.
2. riscv.opt for the target option and variable.
3. riscv_ext_flag_table to bind the extension to its target option.
4. riscv_combine_info if this extension is just a ma
pushed to trunk, thanks :)
On Mon, May 12, 2025 at 5:20 PM Dongyan Chen
wrote:
>
> This patch support ssnpm, smnpm, smmpm, sspm and supm extensions[1].
> To enable GCC to recognize and process ssnpm, smnpm, smmpm, sspm and
> supm extensions correctly at compile time.
>
> [1]https://github.com/ris
This patch is somewhat corrupt...but anyway, fixed and pushed to trunk
On Thu, May 8, 2025 at 12:43 PM Dongyan Chen
wrote:
>
> This patch support zilsd and zclsd[1] extensions.
> To enable GCC to recognize and process zilsd and zclsd extension
> correctly at compile time.
>
> [1] https://github.
Automatically build the ISA extension reference table in invoke.texi from
the unified riscv-ext.def metadata, ensuring documentation stays in sync
with extension definitions and reducing manual maintenance.
gcc/ChangeLog:
* doc/invoke.texi: Replace hand‑written extension table with
Refactor extension flag handling by removing the old riscv_ext_flag_table and
sourcing all flag definitions directly from the flags field of the unified
riscv_ext_info_t structures generated from riscv-ext.def.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_extra_ext_flag_tab
Define a new riscv_ext_info_t struct to aggregate all ISA extension fields
(name, version, flags, implied extensions, bitmask and extra flags) generated
from riscv-ext.def.
Also adjust riscv_ext_flag_table_t and riscv_implied_info_t to make it
able to not hold extension name, this part will refact
We don't hold any extenison flags in `target_flags`, so no need to
gather the extenison flags in `target_flags`.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_can_inline_p): Drop
extension flags check from `target_flags`.
* config/riscv/riscv-subset.h (riscv_
Leverage the centralized riscv-ext.def definitions to auto-generate
the target option parsing and associated internal flags, replacing
manual listings in riscv.opt; `riscv_ext_flag_table` part will remove in
later patch.
gcc/ChangeLog:
* config/riscv/gen-riscv-ext-opt.cc: New.
* c
This commit drops the riscv_ext_version_table and instead uses the
riscv_ext_info_t data structure to provide the version information
for RISC-V extensions.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_ext_version_table):
Remove.
(standard_extensions_p): Use
Consolidate implied-extension logic by removing the old `riscv_implied_info`
array and using the `implied_exts` field in the unified riscv_ext_info_t
structures generated from `riscv-ext.def`.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_implied_info::riscv_implied_
Adding a new ISA extension to RISC-V GCC requires modifying several places:
1. riscv_ext_version_table for the extension version.
2. riscv.opt for the target option and variable.
3. riscv_ext_flag_table to bind the extension to its target option.
4. riscv_combine_info if this extension is just a ma
Pushed to the trunk :)
On Mon, May 5, 2025 at 10:03 PM Jeff Law wrote:
>
>
>
> On 5/4/25 8:13 PM, Kito Cheng wrote:
> > gcc/testsuite/ChangeLog:
> >
> > PR target/120054
> > * gcc.target/riscv/predef-19.c: Adjust testcase.
> If you think it
t; cc1plus: all warnings being treated as errors
>
> https://builder.sourceware.org/buildbot/#/builders/338/builds/150
>
> On Wed, Apr 30, 2025 at 05:25:34PM +0800, Kito Cheng wrote:
> [...]
> > > diff --git a/gcc/config/riscv/genrvv-type-indexer.cc
> b/gcc/config/riscv/genrvv-type-indexer.cc
gcc/testsuite/ChangeLog:
PR target/120054
* gcc.target/riscv/predef-19.c: Adjust testcase.
---
gcc/testsuite/gcc.target/riscv/predef-19.c | 4
1 file changed, 4 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/predef-19.c
b/gcc/testsuite/gcc.target/riscv/predef-19.c
pushed to trunk
On Tue, Apr 29, 2025 at 9:16 PM Kito Cheng wrote:
>
> 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:
>
>
pushed to trunk
On Tue, Apr 29, 2025 at 9:14 PM Kito Cheng wrote:
>
> From: yulong
>
> This version is same as v5, but rebase to trunk, send out to trigger CI.
>
> This commit adds intrinsics support for Xsfvcp extension.
> Diff with V4: Delete the sifive_vector.h fil
1 - 100 of 1343 matches
Mail list logo
