[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #13 from Li Pan --- Spec has two sentences about this: [1] These instructions are intended to be used to save and restore vector registers when the type or length of the current contents of the vector register is not known, or where modifying vl and vtype would be costly. [2] The instructions operate with an effective vector length, evl=NFIELDS*VLEN/EEW, regardless of current settings in vtype and vl. The usual property that no elements are written if vstart ≥ vl does not apply to these instructions. Instead, no elements are written if vstart ≥ evl. Does the second one indicates it will not be illegal no matter what vtype and vl are?
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 Kito Cheng changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #12 from Kito Cheng --- Let us summon the RISC-V judge!!!
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #11 from Robin Dapp --- > Yes. I am sure. And SPIKE and QEMU have no problem. So vlre/vsre should execute despite a VILL in VTYPE? At first sight I don't find any specifics in the vector spec. qemu is not very pedantic in that respect, I believe it didn't fault for vmv1r either. Never tried spike, though. That might be a question for Kito.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #3 from Kito Cheng --- Sounds like PR117544?
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #10 from JuzheZhong --- (In reply to Robin Dapp from comment #9) > > No. vlre should not depend on vtype. It should be hardware bug. > > Are you sure about that? vmv1r also doesn't depend on a specific vtype, > each one is OK, but the vtype must at least be valid. So we get a SIGILL > for an invalid vtype (i.e. when clobbered by a syscall). > > I mean I wouldn't mind not fixing this if it's indeed a hardware issue but > e.g. the Banana Pi is widespread and it might look unfortunate if we just > SIGILL for a preventable reason. Yes. I am sure. And SPIKE and QEMU have no problem.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #9 from Robin Dapp --- > No. vlre should not depend on vtype. It should be hardware bug. Are you sure about that? vmv1r also doesn't depend on a specific vtype, each one is OK, but the vtype must at least be valid. So we get a SIGILL for an invalid vtype (i.e. when clobbered by a syscall). I mean I wouldn't mind not fixing this if it's indeed a hardware issue but e.g. the Banana Pi is widespread and it might look unfortunate if we just SIGILL for a preventable reason.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #8 from JuzheZhong ---
(In reply to Robin Dapp from comment #6)
> (In reply to Kito Cheng from comment #5)
> > Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg
> > load store
>
> On the Banana Pi I get a SIGILL for
>
> int
> main() {
> asm volatile ("lui a5, 0xdd\n\t"
> "add a5, a5, 904\n\t"
> "vl1re32.v v1,(a5)\n\t"
> :
> :
> :);
>
> return 0;
> }
>
> but a SIGSEGV (which is OK) for
>
> int
> main() {
> asm volatile ("lui a5, 0xdd\n\t"
> "add a5, a5, 904\n\t"
> "vsetivlizero,8,e32,m1,ta,ma\n\t"
> "vl1re32.v v1,(a5)\n\t"
> :
> :
> :);
>
> return 0;
> }
>
> So looks like we also need a vtype for the loads and stores?
No. vlre should not depend on vtype. It should be hardware bug.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #7 from Li Pan --- Does it possible that the board has set such insn to illegal insn by mistake? The qemu and spike doesn't report any illegal insn. I will go thru the spec for more details. Ideally, the vl1re32.v has the vtype info already.
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #6 from Robin Dapp ---
(In reply to Kito Cheng from comment #5)
> Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg
> load store
On the Banana Pi I get a SIGILL for
int
main() {
asm volatile ("lui a5, 0xdd\n\t"
"add a5, a5, 904\n\t"
"vl1re32.v v1,(a5)\n\t"
:
:
:);
return 0;
}
but a SIGSEGV (which is OK) for
int
main() {
asm volatile ("lui a5, 0xdd\n\t"
"add a5, a5, 904\n\t"
"vsetivlizero,8,e32,m1,ta,ma\n\t"
"vl1re32.v v1,(a5)\n\t"
:
:
:);
return 0;
}
So looks like we also need a vtype for the loads and stores?
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #4 from Robin Dapp --- > I see, but when I changed to > > addia5,a5,912 > > aka load from 0xdd390, the board still has the illegal insn. 0xdd390 is > aligned for -O2 -march=rv64gcv -mrvv-vector-bits=zvl build, right? Hmm, right, I was mistaken. The original one (904) also is not element misaligned (for 32-bit = 4 byte elements). So no alignment issue. Is it a vsetvl problem? We added vsetvl handling for full-register moves, do we also need it for full-register loads and stores?
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #5 from Kito Cheng --- Oh, vsetvli/vill issue should only appeared for whole reg move not whole reg load store
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #2 from Li Pan --- (In reply to Robin Dapp from comment #1) > That's a misaligned vector load I suppose? I see, but when I changed to addia5,a5,912 aka load from 0xdd390, the board still has the illegal insn. 0xdd390 is aligned for -O2 -march=rv64gcv -mrvv-vector-bits=zvl build, right?
[Bug c++/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #1 from Robin Dapp --- That's a misaligned vector load I suppose?
