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 res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362
--- Comment #1 from Robin Dapp ---
That's a misaligned vector load I suppose?
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 SIG
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, 0
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, righ
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at gcc dot gnu.org
Target Milestone: ---
Target: riscv
x264 contains a variation of the following loop (in hpel_filter):
typedef unsigned char uint8_t;
typedef short int16_t;
inline
uint8_t
x264_clip_uint8
|--- |FIXED
CC||rdapp at gcc dot gnu.org
--- Comment #2 from Robin Dapp ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #4 from Robin Dapp ---
I can reproduce this, but only with a qemu VLEN=128, VLEN >= 256 result in the
correct value of 234635118.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #11 from Robin Dapp ---
Tried building highway to reproduce and hit another error in fre...
Do we have a minimal example for this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #4 from Robin Dapp ---
Does it make sense to have the vmax/vmin/truncate pattern as a fallback for
other targets? On riscv it would save one predicated instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #3 from Robin Dapp ---
vnclipu is basically a scaling (narrowing), rounding shift with subsequent
"clip" i.e. saturation. Its input and output is unsigned, though, so for the
function above we first need to "clip" the negative value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
--- Comment #14 from Robin Dapp ---
I managed to have a look now but the whole builtin and LTO machinery is kind of
new to me.
As Andreas mentioned already the issue is that we do not register vector
builtins when the current target is !TARGET_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #3 from Robin Dapp ---
> We could use scatter stores, building the index vector somehow cleverly with
> i_width contiguous indexes interspaced by i_dst_stride. In fact this vector
> could be built as inductions when building the i_h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #5 from Robin Dapp ---
> Well, consider the desired index vector being a real induction (just
> store it somewhere). If we can handle that, we should be able to
> handle the scatter. If not, we can't handle the scatter.
Hmm, I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120687
--- Comment #3 from Robin Dapp ---
Yeah, for 8 elements we still have a mode but beyond 8 we at least cannot do a
segment access anymore. Then we try with even/odd or interleaved permutations.
I kind of wonder why the cost model doesn't reject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #3 from Robin Dapp ---
(In reply to Jeffrey A. Law from comment #2)
> Yea, this bug may have been filed while we were discussing it in a team
> meeting.
>
> I think the question is whether or not to include the new guards in the
> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
Robin Dapp changed:
What|Removed |Added
Last reconfirmed||2025-6-23
--- Comment #1 from Robin Dapp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120459
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #1 from Robin Dapp ---
I'm just realizing that without knowing the stride statically, we'd generate a
lot of code as we don't have a way of setting an element size for loads
dynamically. Although riscv offers a dynamic element size
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: riscv
In x264 we have several variations of the following loop:
void foo (uint8_t *dst, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
Robin Dapp changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #8 from Robin Dapp ---
The vlse comes from a vec_duplicate:V2DI that has a reg pointing to a
"real(kind=4)", so a float.
What's interesting, though, is that the MEM is supposedly 64-bit aligned (see
below, A64).
(insn 285 282 287 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #7 from Robin Dapp ---
Ok, I was able to reproduce it with r15-9904-g2498cbbcdb23da.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #5 from Robin Dapp ---
I tried reproducing this with a recent trunk (r16-1965-gc512c9090f52e7) but
didn't see the exact code sequence. wrf also ran to completion on the Banana
Pi.
Did you use a stock GCC 15.1 or a specific commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121073
--- Comment #2 from Robin Dapp ---
Yes, the issue is that Wdm was a memory constraint before, giving reload more
freedom. In the case here we have a real mask operand that only the strided
alternatives support. Need to think of another solutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121126
--- Comment #5 from Robin Dapp ---
I'll have a look. I'm currently tied down with other things, so maybe next
week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #6 from Robin Dapp ---
(In reply to Tamar Christina from comment #5)
> Question, can I count on
>
> -march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8
>
> always being available as a codegen option for RVV? or do I nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120461
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120461
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
|--- |FIXED
CC||rdapp at gcc dot gnu.org
--- Comment #2 from Robin Dapp ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120930
Robin Dapp changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rdapp at gcc dot gnu.org
|RESOLVED
CC||rdapp at gcc dot gnu.org
--- Comment #3 from Robin Dapp ---
Fixed on trunk. I don't suppose we want to backport this as it's pretty
harmless (all div variants expand to u/sdiv anyway)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734
Robin Dapp changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #5 from Robin Dapp ---
Tried to reproduce again with the latest trunk and didn't succeed. I'm always
getting 234635118 no matter the VLEN and options. I'll try to bisect a failing
commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #6 from Robin Dapp ---
I was able to reproduce it on our internal tree. Disabling scheduling as well
as using the simple vsetvl strategy make the problem disappear so everything
points to a vsetvl issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
--- Comment #7 from Robin Dapp ---
Picking a random commit in May (r16-649-g5c012971969db9) also shows the issue.
It looks as if we pick the wrong LMUL for a store and this rule is to blame:
DEF_SEW_LMUL_RULE (
ratio_and_ge_sew, sew_only, se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120930
--- Comment #2 from Robin Dapp ---
I'm seeing a difference between -O2 and -O3 where the -O2 version gets the
proper result (3). In the -O3 version we completely unroll the loop but don't
seem to populate the "b" array entirely but just the fir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
Robin Dapp changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #8 from Robin Dapp -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121065
--- Comment #3 from Robin Dapp ---
Should be fixed. My armhf qemu tests weren't really successful due to a qemu
configuration issue. I did verify that the test here (and others) don't ICE,
of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121073
--- Comment #1 from Robin Dapp ---
That's very likely due to my recent broadcast changes. Will have a look.
401 - 443 of 443 matches
Mail list logo
