Re: [PATCH] RISC-V: Implment H modifier for printing the next register name

On Sun, 4 May 2025 08:45:25 -0600, Jeff Law wrote: > > > On 4/27/25 1:28 AM, Jin Ma wrote: > > For RV32 inline assembly, when handling 64-bit integer data, it is > > often necessary to process the lower and upper 32 bits separately. > > Unfortunately, we can only outpu

[RFC] RISC-V: Implment H modifier for printing the next register name

For RV32 inline assembly, when handling 64-bit integer data, it is often necessary to process the lower and upper 32 bits separately. Unfortunately, we can only output the current register name (lower 32 bits) but not the next register name (upper 32 bits). To address this, the modifier 'H' has be

Re: [RFC] RISC-V: The optimization ignored the side effects of the rounding mode, resulting in incorrect results.

On Tue, 18 Feb 2025 13:48:02 -0700, Jeff Law wrote: > > > On 2/18/25 4:12 AM, Jin Ma wrote: > > We overlooked the side effects of the rounding mode in the pattern, > > which can impact the result of float_extend and lead to incorrect > > optimizations in the final

[RFC] RISC-V: The optimization ignored the side effects of the rounding mode, resulting in incorrect results.

/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/bug-11.c: New test. Reported-by: CunJian Huang Signed-off-by: Jin Ma --- gcc/config/riscv/vector-iterators.md | 3 +++ gcc/config/riscv/vector.md| 6 +++-- .../gcc.target/riscv/rvv/base/bug-11.c| 24

Re: [PATCH] RISC-V: Bugfix ICE for RVV intrinisc when using no-extension parameters

On Mon, 17 Feb 2025 22:49:47 -0700, Jeff Law wrote: > > > On 2/15/25 10:40 PM, Jin Ma wrote: > > On Sun, 16 Feb 2025 11:59:37 +0800, Jeff Law wrote: > >> > >> > >> On 2/14/25 12:12 AM, Jin Ma wrote: > >>> When using riscv_v_abi, the return an

Re: [PATCH] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

/riscv/rvv/base/pr117955.c > @@ -0,0 +1,827 @@ > +/* { dg-do compile } */ > +/* { dg-options "-march=rv64gcv_zvfh -O3" } */ Here are three issues with this test case: 1. The test case does not seem to take effect, as it appears to pass both before and after applying the pa

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB_OS hook to override multi-lib-os result.

On Thu, 27 Feb 2025 19:43:30 +0800, Kito Cheng wrote: > Hi Jin Ma: > > I realized multilib os dir is not correctly set as you described, but > I think that info should just come from multilib_select rather than > creating a new hook to do that, anyway I just wrote a fix...becaus

Re: [PATCH] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

e the issue. If all goes as expected, you will encounter a "Segmentation fault (core dumped)." By disassembling the binary, you'll notice the presence of "vsetvli zero,zero,e32,m4,ta,ma", which is where the problem lies, just as I mentioned previously. Best regards, J

Re: [PATCH] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

patch works around that by adjusting the ratio without touching > LMUL. But that still leaves us with PR117955 where the ratio is "correct" > but > invalid. > > Given all this, I think the only way to fix this is to re-use/copy the vsetvl > information from either prev or next (as in my patch). > > I'm going to change bug-10.c into a run test, add the test you last provided > as > a run test as well as well as your reduced test from PR117955. LGTM :) Best regards, Jin Ma > -- > Regards > Robin

Re: [PATCH] RISC-V: Adjust LMUL when using maximum SEW [PR117955].

_riscv_vsll_vx_u8mf8 (__riscv_vid_v_u8mf8 (f), 2, f); vfloat16mf4_t g; a (1); g = __riscv_vfmv_s_f_f16mf4 (2, f); vfloat64m1_t i = __riscv_vfmv_s_f_f64m1 (30491, f); vuint16mf4_t j; __riscv_vsoxei16_v_f16mf4 (e, j, g, f); vuint8mf8_t k = __riscv_vsll_vx_u8mf8 (__risc

Re: [v5,2/4] RISC-V: Add Zicfilp ISA extension

Hi, Monk Chiang I noticed that at -O0, static functions are emitting lpad instructions, whereas they do not at -O2. I'm not sure if this is expected behavior. Upon further investigation, I found that c_node->only_called_directly_p() returns false, which is caused by force_output being set to 1.

[PATCH 1/2] Add TARGET_COMPUTE_MULTILIB_OS hook to override multi-lib-os result.

Create a new hook to let target could override the multi-lib-os result. The motivation for this change arises from the fact that using TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead to unexpected behavior with multilib_os_dir. In our build scripts, we establish a connectio

[PATCH 2/2] RISC-V: Implement TARGET_COMPUTE_MULTILIB_OS

According to the definition in gcc/config/riscv/t-linux, after obtaining the reused multilib_dir result using TARGET_COMPUTE_MULTILIB, we should set multilib_os_dir to its parent directory. For example, when building GCC with the options "--enable-multilib --with-arch=rv64gc --with-abi=lp64d" and

[PATCH] RISC-V: Bugfix ICE for RVV intrinisc when using no-extension parameters

When using riscv_v_abi, the return and arguments of the function should be adequately checked to avoid ICE. PR target/118872 gcc/ChangeLog: * config/riscv/riscv.cc (riscv_fntype_abi): Strengthen the logic of the check to avoid missing the error report. gcc/testsuite/Chan

Re: [RFC] RISC-V: The optimization ignored the side effects of the rounding mode, resulting in incorrect results.

tions about the rounding modes in floating-point calculations, such as in float_extend, which may prevent CSE optimizations. Could this also lead to lost optimization opportunities in other areas that don't require this option? I'm not sure. I suspect that the best approach would be to

Re: [RFC] RISC-V: The optimization ignored the side effects of the rounding mode, resulting in incorrect results.

On Tue, 18 Feb 2025 21:40:06 -0700, Jeff Law wrote: > > > On 2/18/25 7:30 PM, Jin Ma wrote: > > > > > I apologize for not explaining things more clearly. I also discovered that > > the issue is caused by CSE. I think that during the substitution process, &g

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB_OS hook to override multi-lib-os result.

On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote: > Create a new hook to let target could override the multi-lib-os result. > > The motivation for this change arises from the fact that using > TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead > to unexpecte

Re: [PATCH 2/2] RISC-V: Implement TARGET_COMPUTE_MULTILIB_OS

ted to lib32/ilp32d, such as b1(lib32/ilp32d) -> b2(lib32/ilp32d) -> b3(lib32/ilp32d) -> However, the current situation is a1(lib32/ilp32d) -> a2(lib64/lp64d) -> a3(lib64/lp64d) -> Clearly, we are traversing the wrong paths before reaching the sysroot. In realit

[PATCH] RISC-V: Disable unsupported vsext/vzext patterns for XTheadVector.

XThreadVector does not support the vsext/vzext instructions; however, due to the reuse of RVV optimizations, it may generate these instructions in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2'," we should disable these patterns. gcc/ChangeLog: * config/riscv/vector.md

Re: [PATCH] RISC-V: Since the loop increment i++ is unreachable, the loop body will never execute more than once

On Fri, 16 May 2025 09:18:45 -0600, Jeff Law wrote: > > > On 5/16/25 1:32 AM, Jin Ma wrote: > > Reported-by: huangcunjian > > > > gcc/ChangeLog: > > > > * config/riscv/riscv.cc (riscv_gpr_save_operation_p): Remove > > break and fixbug for

Re: [PATCH v2] driver: Fix multilib_os_dir and multiarch_dir for those target use TARGET_COMPUTE_MULTILIB

cc.c (find_multilib_os_dir_by_multilib_dir): New. > > (set_multilib_dir): Fix multilib_os_dir and multiarch_dir > > if multilib_os_dir is not set. > Given the fact this code is shared and I don't have a good handle on its > behavior and how the change potentially affects other targets, I'm > inclined to ask for this to wait for gcc-16 development to open and > backport into gcc-15.2 after soak time on the trunk. > > Jeff Hi,I think this patch is essential. Can we proceed to push it to the trunk now? Best regards, Jin Ma

[PATCH] RISC-V: Since the loop increment i++ is unreachable, the loop body will never execute more than once

Reported-by: huangcunjian gcc/ChangeLog: * config/riscv/riscv.cc (riscv_gpr_save_operation_p): Remove break and fixbug for elt index. --- gcc/config/riscv/riscv.cc | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/ris

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

> > When testing a extension, it is often necessary for a certain program not to > > need some kind of extension, such as the bitmanip extension, to evaluate the > > performance or codesize of the extension. However, the current multilib > > rules > > will report an error when it is not a superset

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

> > > > When testing a extension, it is often necessary for a certain program > > > > not to > > > > need some kind of extension, such as the bitmanip extension, to > > > > evaluate the > > > > performance or codesize of the extension. However, the current multilib > > > > rules > > > > will rep

[PATCH] In the pipeline, UNRECOG INSN is not executed in advance if it starts a live range.

Unrecog insns (such as CLOBBER, 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

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

Reference: https://github.com/gcc-mirror/gcc/commit/d0bc0cb66bcb0e6a5a5a31a9e900e8ccc98e34e5 RISC-V should also be implemented to handle no_insn patterns for pipelining. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_sched_variable_issue): New function. (TARGET_SCHED_VARIABLE_ISS

[RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

hi, Are there any new developments about Zfb? Are there any plans to implement the Zvfbfmin and Zvfbfwma expansion? I see that Zfb is being reviewed in llvm, maybe we should do the same on gcc. Ref: https://reviews.llvm.org/D151313 https://reviews.llvm.org/D150929

Re: [PATCH] In the pipeline, UNRECOG INSN is not executed in advance if it starts a live range.

ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619951.html Ref: http://patchwork.ozlabs.org/project/gcc/patch/20230323080734.423-1-ji...@linux.alibaba.com/

Re: [PATCH] In the pipeline, UNRECOG INSN is not executed in advance if it starts a live range.

> On 5/29/23 04:51, Jin Ma wrote: > >Unrecog insns (such as CLOBBER, 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 re

[PATCH] RISC-V: Save and restore FCSR in interrupt functions to avoid program errors.

gcc/ChangeLog: * config/riscv/riscv.cc (riscv_compute_frame_info): Allocate frame for FCSR. (riscv_for_each_saved_reg): Save and restore FCSR in interrupt functions. * config/riscv/riscv.md (riscv_frcsr): New patterns. (riscv_fscsr): Likewise. gcc/testsuite/Chang

[PATCH v2] RISC-V: Save and restore FCSR in interrupt functions to avoid program errors.

In order to avoid interrupt functions to change the FCSR, it needs to be saved and restored at the beginning and end of the function. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_compute_frame_info): Allocate frame for FCSR. (riscv_for_each_saved_reg): Save and restore FCSR in i

Re: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

> diff --git a/gcc/common/config/riscv/riscv-common.cc > b/gcc/common/config/riscv/riscv-common.cc > index ebc1ed7d7e4..2b3ff1f5b8e 100644 > --- a/gcc/common/config/riscv/riscv-common.cc > +++ b/gcc/common/config/riscv/riscv-common.cc > @@ -102,6 +102,8 @@ static const riscv_implied_info_t riscv_i

Re: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

> diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md > index 5b70ab20758..6349f032bc8 100644 > --- a/gcc/config/riscv/iterators.md > +++ b/gcc/config/riscv/iterators.md > @@ -61,10 +61,15 @@ > ;; Iterator for hardware-supported floating-point modes. > (define_mode_iterator

[PATCH] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred: /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal operand

[PATCH v2] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal operand

Re: [PATCH] RISC-V: Fixbug for fsflags instruction error using immediate.

> Hi Jin, > > this looks reasonable. Would you mind adding (small) test cases > still to make sure we don't accidentally reintroduce the problem? > > Regards > Robin Ok, I have already sent the v2 version, please review it again, thanks. Link: https://gcc.gnu.org/pipermail/gcc-patches/2023-Ju

[PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal operand

Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

> - [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)] > + [(unspec_volatile [(match_operand:SI 0 "csr_operand" "r")] UNSPECV_FSCSR)] > > If you don't allow immediate value in range 0 ~ 31, it should be > "register_operand" instead of "csr_operand". > > I think direc

Re: Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

;csr_operand" "r")] > > UNSPECV_FSCSR)] > >"TARGET_HARD_FLOAT || TARGET_ZFINX" > >"fscsr\t%0") > > > > This pattern never allows immediate in the constraint. Why still make > > predicate allow immediate? > > > &g

[PATCH v4] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal operand

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

> On 5/29/23 06:46, Jeff Law wrote: > > > > > > On 5/29/23 05:01, Jin Ma wrote: > >> Reference: > >> https://github.com/gcc-mirror/gcc/commit/d0bc0cb66bcb0e6a5a5a31a9e900e8ccc98e34e5 > >> > >> RISC-V should also be implemented to ha

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

> Hi Jin Ma, > > On 5/16/23 00:06, jinma via Gcc-patches wrote: > > On 5/15/23 07:16, Jin Ma wrote: > >> > >> Do we also need to check Z[FDH]INX too? > >> > >> Otherwise it looks pretty good. We just need to wait for everything to >

[PATCH v10] RISC-V: Add support for the Zfa extension

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is: 1, According to riscv-spec, "The FCVTMO

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

> > Hi Jin Ma, > > > > On 5/16/23 00:06, jinma via Gcc-patches wrote: > > > On 5/15/23 07:16, Jin Ma wrote: > > >> > > >> Do we also need to check Z[FDH]INX too? > > >> > > >> Otherwise it looks pretty good. We just nee

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

Additional links： v10, the patch that needs to be reviewed again: http://patchwork.ozlabs.org/project/gcc/patch/20230814055033.1995-1-ji...@linux.alibaba.com/ v9 and the previous review comments: http://patchwork.ozlabs.org/project/gcc/patch/20230515131628.953-1-ji...@linux.alibaba.com/ Zfa patch

[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: [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: [2/2] RISC-V: Constant FP Optimization with 'Zfa'

On 2023/08/15 12:38, Tsukasa OI wrote: > > On 2023/08/14 21:51, Jin Ma wrote: > >> Hi Tsukasa, > >> What a coincidence, I also implemented zfa extension, which also > >> includes fli related instructions :) > > > > Hi, I'm glad to k

[PATCH] RISC-V: When the TARGET_COMPUTE_MULTILIB hook is implemented, check the version of each extension.

When there is an extension with different versions, the result of the TARGET_COMPUTE_MULTILIB hook is generally wrong, so the version needs to be considered. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_subset_list::match_score): Match the version of each extensio

[PATCH] RISC-V: Don't report an error until the link phase if suitable multilib isn't found.

When suitable multilib isn't found, an error is not reported until the link period, which is inconsistent with the result of compiling option `-print-multi-directory`. For example, when suitable multilib isn't found, the return result of `-print-multi-directory` is the default value '.', while the

[PATCH v6] RISC-V: Add support for experimental zfa extension.

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7 latest 'Zfa' change on the master branch of the RISC-V ISA Manual as of this writing. The Wiki Page (details): https://github.com/a4lg/binu

[PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is: 1, The immediate number of the instruct

[PATCH] Fix type error of 'switch (SUBREG_BYTE (op)).'

For example: (define_insn "mov_lowpart_sidi2" [(set (match_operand:SI0 "register_operand" "=r") (subreg:SI (match_operand:DI 1 "register_operand" " r") 0))] "TARGET_64BIT" "mov\t%0,%1") (define_insn "mov_highpart_sidi2" [(set (match_operand:SI0 "register_ope

[PATCH] RISC-V: Remove trailing spaces on lines.

gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Remove trailing spaces on lines. * config/riscv/riscv.cc (riscv_legitimize_move): Likewise. * config/riscv/riscv.h (enum reg_class): Likewise. * config/riscv/riscv.md: Likewise. --- gcc/common/config/ris

[PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

When testing a extension, it is often necessary for a certain program not to need some kind of extension, such as the bitmanip extension, to evaluate the performance or codesize of the extension. However, the current multilib rules will report an error when it is not a superset of the MULTILIB_REQU

Re: [PATCH] Fix type error of 'switch (SUBREG_BYTE (op)).'

> > On 5/17/23 03:03, Jin Ma wrote: > >> For example: > >> (define_insn "mov_lowpart_sidi2" > >>[(set (match_operand:SI0 "register_operand" "=r") > >> (subreg:SI (match_operand:DI 1

[PATCH] RISC-V: In pipeline scheduling, insns should not be fusion in different BB blocks.

When the last insn1 of BB1 and the first insn2 of BB2 are fusion, insn2 will clear all dependencies in the function chain_to_prev_insn, resulting in insn2 may mov to any BB, and the program calculation result is wrong. gcc/ChangeLog: * sched-deps.cc (sched_macro_fuse_insns): Insns should

[PATCH] RISC-V: Add the option "-mno-multilib-check" to disable multilib checks.

When testing a extension, it is often necessary for a certain program not to need some kind of extension, such as the bitmanip extension, to evaluate the performance or codesize of the extension. However, the current multilib rules will report an error when it is not a superset of the MULTILIB_REQU

[PATCH v4] [RISCV] Add 'Zfa' extension according to riscv-isa-manual

This patch adds the 'Zfa' extension for riscv, which is based on: ( https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7 ) latest 'Zfa' change on the master branch of the RISC-V ISA Manual as of this writing. The Wiki Page (details): ( https://github.com/a4lg

[PATCH] RISC-V: Added zvfh support for zfa extensions.

This is a follow-up for the zfa extension, added according to the recommendations for zvfh and patch of Tsukasa OI . At the same time, zfa-fli-5.c of which is also based on the patch. Ref: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627284.html https://gcc.gnu.org/pipermail/gcc-patches

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

ping Ref: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627341.html https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621296.html

[PATCH v8] RISC-V: Add the 'zfa' extension, version 0.2.

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb https://github.com/riscv/riscv-isa-manual/commit/1f038182810727f5feca311072e630d6baac51da The binutils-gdb for 'Zfa' extension: https://github.com/a4lg/binutils-gdb/commit

Re: [PATCH v8] RISC-V: Add the 'zfa' extension, version 0.2.

On 4/19/23 03:57, Jin Ma wrote: > This patch adds the 'Zfa' extension for riscv, which is based on: >https://github.com/riscv/riscv-isa-manual/commits/zfb > https://github.com/riscv/riscv-isa-manual/commit/1f038182810727f5feca311072e630d6baac51da > >

[PATCH v5] [RISCV] Add 'Zfa' extension according to riscv-isa-manual

This patch adds the 'Zfa' extension for riscv, which is based on: ( https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7 ) latest 'Zfa' change on the master branch of the RISC-V ISA Manual as of this writing. The Wiki Page (details): ( https://github.com/a4lg

[PATCH] RISC-V: Fix bug of TARGET_COMPUTE_MULTILIB implemented in riscv.

MAX_MATCH_SCORE is not assigned anywhere except initialized to 0, causing BEST_MATCH_MULTI_LIB to always be 0 or -1, which will cause the result of TARGET_COMPUTE_MULTILIB hook to fail. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: --- gcc/common/config/riscv/riscv-common.cc | 5

[PATCH v1] RISC-V: Change the generation mode of ADJUST_SP_RTX from gen_insn to gen_SET.

The gen_insn method is used to generate ADJUST_SP_RTX here, which has certain potential risks: When the architecture adds pre-processing to `define_insn "adddi3"`, such as `define_expend "adddi3"`, the gen_expand will be automatically called here, causing the patern to emit directly, which will ca

[PATCH] In the ready lists of pipeline, put unrecog insns (such as CLOBBER, USE) at the latest to issue.

Unrecog insns (such as CLOBBER, 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

[PATCH] RISC-V: Adjust the parsing order of extensions to be consistent with riscv-spec and binutils.

The current order of gcc and binutils parsing extensions is inconsistent. According to latest risc-v spec, the canonical order in which extension names must appear in the name string specified in Table 29.1 is different from before. In the latest table, non-standard extensions must be listed aft

[PATCH] Fixed typo.

gcc/ada/ChangeLog: * gcc-interface/utils.cc (unchecked_convert): Fixed typo. --- gcc/ada/gcc-interface/utils.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/ada/gcc-interface/utils.cc b/gcc/ada/gcc-interface/utils.cc index 392ec0b7f4e..0c4f8b90c8e 100644 --- a/g

<    1   2