https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125215
--- Comment #3 from Robin Dapp <rdapp at gcc dot gnu.org> ---
(In reply to Zhongyao Chen from comment #2)
> Sorry for the misinfo; GIMPLE IL is correct.
>
> After deeper digging, the root cause is in riscv-v.cc, when synthesizing
> interleaved vectors (e.g., e8) using a wider mode (e.g., e16). The 8-bit
> arithmetic overflow into the upper bits of the 16-bit container. This
> corrupts the high sequence elements during the final vor.vv merge.
>
> here is my minimal reproduction testcase:
>
> ---------------------------------------------
> #include <stdint-gcc.h>
>
> __attribute__((noipa))
> void foo(uint8_t *d)
> {
> d[0] = 128; d[1] = 135; d[2] = 130; d[3] = 149;
> d[4] = 132; d[5] = 163; d[6] = 134; d[7] = 177;
> d[8] = 136; d[9] = 191; d[10] = 138; d[11] = 205;
> d[12] = 140; d[13] = 219; d[14] = 142; d[15] = 233;
> }
>
> int main()
> {
> uint8_t d[16];
> uint8_t e[] = {128, 135, 130, 149, 132, 163, 134, 177, 136, 191, 138, 205,
> 140, 219, 142, 233};
> foo(d);
> for (int i = 0; i < 16; i++)
> if (d[i] != e[i])
> __builtin_abort ();
> return 0;
> }
> ---------------------------------------------
>
> reproduce log:
> $ riscv64-unknown-linux-gnu-gcc -O3 -march=rv64gcv -fno-vect-cost-model
> foo.c -o /tmp/foo
> $ qemu-riscv64 /tmp/foo
> [1] 2692843 IOT instruction (core dumped) qemu-riscv64 /tmp/foo
Thanks for the analysis. I thought we had fixed this already, but apparently
not :/ I can take this, or do you want to continue?
