https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #22 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c656d268c9dac8b6f710b9bbd399214cb11b3287
commit r14-5635-gc656d268c9dac8b6f710b9bbd399214cb11b3287
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #21 from Li Pan ---
(In reply to Robin Dapp from comment #18)
> I did a quick testsuite run on rv32 and can confirm that this fixes the
> issue for me.
Confirmed that this fixes the issue on RV64 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #20 from Andrew Pinski ---
(In reply to Tamar Christina from comment #19)
> I have noticed some other gather related failures but haven't had time to
> triage them to file bugs. Hoping to get to that soon.
I had noticed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #18 from Robin Dapp ---
I did a quick testsuite run on rv32 and can confirm that this fixes the issue
for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #17 from Richard Biener ---
OK, so for RISC-V with the testcase from the description there's the
following issue:
_179 = [(uint8_t *)_618];
_225 = BIT_FIELD_REF [(uint8_t *)_179], 8,
16>;
...
vect__8.9_405 = {_218, _224,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #16 from Richard Biener ---
The IL I see for f_int16_t_int8_t on aarch64 looks OK to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #15 from rguenther at suse dot de ---
On Mon, 20 Nov 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
>
> --- Comment #11 from JuzheZhong ---
> Hi, Richard.
>
> I come back to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #14 from JuzheZhong ---
Just confirm on aarch64 QEMU, it seems that ARM SVE has the same issue as RVV.
This is the test:
#include
#define TEST_LOOP(DATA_TYPE, INDEX_TYPE)
\
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #13 from JuzheZhong ---
Created attachment 56649
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56649=edit
Correct vectorized optimized dump
This is the optimized dump IR that runs correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #12 from JuzheZhong ---
Created attachment 56648
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56648=edit
Optimized dump which is buggy
This is the buggy vectorized dump IR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #11 from JuzheZhong ---
Hi, Richard.
I come back to revisit this bug.
I found if I do this:
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 4a09b3c2aca..2fd128672b9 100644
--- a/gcc/tree-vect-slp.cc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #10 from JuzheZhong ---
(In reply to Richard Biener from comment #9)
> Does it still occur after the last round of fixes?
Hi, Richard. The FAIL still exists. We will revisit it later to see whether it
is RISC-V backend issue.
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #9 from Richard Biener ---
Does it still occur after the last round of fixes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #8 from Li Pan ---
Still fail in upstream.
../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc -march=rv64imafdcv
-mabi=lp64d \
-ftree-vectorize -O3 --param riscv-autovec-preference=fixed-vlmax \
--param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #7 from Li Pan ---
Seems no luck when --param vect-epilogues-nomask=0. I will have a try with the
newest upstream for this issue if everything look OK, and keep you posted.
../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #6 from Richard Biener ---
So I can see we don't recognize a gather IFN during pattern recog here.
t.c:15:1: note: Final SLP tree for instance 0x502e9a0:
t.c:15:1: note: node 0x4f84700 (max_nunits=128, refcnt=2) vector(32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #5 from Li Pan ---
Thank you, any thing I can help please feel free to let me know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #3 from Li Pan ---
Double confirmed the trunk of GCC still has this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111970
--- Comment #2 from Li Pan ---
Add more information about how to build and run the test cases.
Build:
../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc -march=rv64imafdcv
-mabi=lp64d -ftree-vectorize -O3 --param
22 matches
Mail list logo