[Bug target/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size

2025-05-21 Thread pan2.li at intel dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362

--- Comment #17 from Li Pan  ---
FYI, the spec2017 619 ref size, with --thread > 1 can also trigger this issue,
but with another load.

10cf4:   0287f107vl1re64.v   v2,(a5)

thread = 1 is OK, as above code appears at omp related part, aka
00010cac :.

[Bug target/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size

2025-05-21 Thread kito at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362

--- Comment #16 from Kito Cheng  ---
Not sure how many people care bananapi enough, maybe we could add an option and
tune parameter for that mcpu as work around if any of us feel care :P

[Bug target/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size

2025-05-21 Thread pan2.li at intel dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362

Li Pan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #15 from Li Pan  ---
(In reply to Andrew Waterman from comment #14)
> > Let us summon the RISC-V judge!!!
> 
> The key is that vtype.vill affects only those instructions that depend on
> vtype.  vlr and vsr do not depend on vtype and so are unaffected by
> vtype.vill.
> 
> > vmv1r also doesn't depend on a specific vtype
> 
> This actually isn't the case: unlike vlr and vsr, the vmvr
> instructions' vstart settings are SEW-specific, and so they have a vtype
> dependence.  This is arguably a flaw in the ISA, but the fact is that the
> moves are more restricted than the loads and stores.
> 
> > 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.
> 
> It does seem like a hardware bug, but I'm sympathetic to this point of view,
> assuming we aren't giving anything up by working around it.

I see, thanks Waterman.

It's mostly one hardware bug from my perspective, given that the vmvr
depends on a vtype while vlr and vsr do not. Close this PR.

[Bug target/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size

2025-05-20 Thread andrew at sifive dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362

--- Comment #14 from Andrew Waterman  ---
> Let us summon the RISC-V judge!!!

The key is that vtype.vill affects only those instructions that depend on
vtype.  vlr and vsr do not depend on vtype and so are unaffected by
vtype.vill.

> vmv1r also doesn't depend on a specific vtype

This actually isn't the case: unlike vlr and vsr, the vmvr
instructions' vstart settings are SEW-specific, and so they have a vtype
dependence.  This is arguably a flaw in the ISA, but the fact is that the moves
are more restricted than the loads and stores.

> 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.

It does seem like a hardware bug, but I'm sympathetic to this point of view,
assuming we aren't giving anything up by working around it.