Hi Robin,
> Hmm, ok so that has nothing to do with the rest of the patch but just
> happend to be the same test case.
> So we didn't schedule a vsetvl here because vmv1r doesn't require
> one but the simulation doesn't initialize vtype before the first vsetvl?
> If this is the only instance, I gu
Hi Lehua,
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand
> XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c sca
I see these failing testcases on trunk:
=== gcc: Unexpected
fails for rv64gcv_zfh lp64d medany spike ===
FAIL: gcc.dg/pr42685.c (test for excess errors)
FAIL: gcc.dg/pr45105.c (test for excess errors)
XPASS: gcc.dg/unroll-7.c scan-rtl-dump-not loop2_unroll "Invalid sum"
FAIL: gcc
Hi Robin,
> unrelated but I'm seeing a lot of failing gather/scatter tests on
> master right now.
Are you talking about these FAILs like bellow? If so, If so it should be
caused by a
recent commit from juzhe who is looking at it. If not, I didn't have
these fails
in my local run.
XPASS: g
Hi Lehua,
unrelated but I'm seeing a lot of failing gather/scatter tests on
master right now.
> /* DIRTY -> DIRTY or VALID -> DIRTY. */
> + if (block_info.reaching_out.demand_p (DEMAND_NONZERO_AVL)
> + && vlmax_avl_p (prop.get_avl ()))
> + continue
Hi,
This little patch fix the fail testcase
(gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c)
after apply this patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627121.html).
The specific reason is that the vsetvl pass has bug and this patch
forbidden the fuse of this c
