I don't understand:
(define_insn "riscv_fscsr"
- [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)]
+ [(unspec_volatile [(match_operand:SI 0 "csr_operand" "r")] UNSPECV_FSCSR)]
"TARGET_HARD_FLOAT || TARGET_ZFINX"
"fscsr\t%0")
This pattern never allows immediate in
So I guess you should change `fscsr` to `fscsr%i0` instead of dropping
K from the constraint list?
On Wed, Jul 26, 2023 at 11:42 AM juzhe.zh...@rivai.ai
wrote:
>
> I don't understand:
> (define_insn "riscv_fscsr"
> - [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)]
>
Yes. I agree.
I didn't take a look into SPEC. Not sure whether fcsr has immediate form.
I mean this patch change in 'fcsr' is quite confusing.
You should either fix the assembly code-gen if fcsr has immediate form,
or fix predicate and constraint both (should not fix constraint only).
Thanks.
Consider this following case:
void test_vsoxseg3ei32_v_i32mf2x3(int32_t *base, vuint32mf2_t bindex,
vint32mf2x3_t v_tuple, size_t vl) {
return __riscv_vsoxseg3ei32_v_i32mf2x3(base, bindex, v_tuple, vl);
}
Compiler failed with:
test.c:19:1: internal compiler error: in vl_vtype_info, at
config/r
Thanks a lot for testing and fixing RVV API。
Could you add a simple float16 tuple api test ?
I known the API is so big that we can't add all api tests into testsuite but
adding a simple case will be nice.
By the way, do you have write access?
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-07
On 7/12/23 10:10, Ng YongXiang via Gcc-patches wrote:
Component:
c++
Bug ID:
110057
Bugzilla link:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
Description:
Array should not call virtual destructor of object when array is destructed
ChangeLog:
2023-07-12 Ng YongXiang PR c++
Thanks a lot. I just fw one email about the write-after-approval steps.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of juzhe.zh...@rivai.ai
Sent: Wednesday, July 26, 2023 12:22 PM
To: Li Xu ; gcc-patches
Cc: kito.cheng ; palmer ; Li Xu
Subject: Re: [PATCH] RISC-V: Fix vector t
> So I guess you should change `fscsr` to `fscsr%i0` instead of dropping
> K from the constraint list?
>
Sorry, you are right. I thought you were talking about fsflags,
but I didn't notice it was fscsr. I'll correct it right away.
> On Wed, Jul 26, 2023 at 11:42 AM juzhe.zh...@rivai.ai
> wrote:
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
Hi Mike,
on 2023/7/11 03:59, Michael Meissner wrote:
> In doing other work, I noticed that there was an insn:
>
> vsx_extract_v4sf__load
>
> Which did not have an iterator. I removed the useless .
It actually has a mode iterator, the "P" is used for clobber.
The whole pattern of this de
LGTM.
Thanks for fixing it.
juzhe.zh...@rivai.ai
From: Jin Ma
Date: 2023-07-26 13:41
To: gcc-patches
CC: jeffreyalaw; palmer; richard.sandiford; kito.cheng; philipp.tomsich;
christoph.muellner; rdapp.gcc; juzhe.zhong; jinma.contrib; Jin Ma
Subject: [PATCH v4] RISC-V: Fixbug for fsflags instru
Hi,
Gentle Ping.
I sent a V2 patch as below for an additional fix Python code format error,
which Martin reported, thanks.
Best,
Lehua
contrib/ChangeLog:
* mklog.py: Fix bugs.
---
contrib/mklog.py | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/mklo
101 - 112 of 112 matches
Mail list logo