https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125215
--- Comment #2 from Zhongyao Chen <chenzhongyao.hit at gmail dot com> ---
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
