Jussi, To try to eliminate qemu and gcc, I've done some more testing:
I run this test case on a Banana BPI-F3 with Spacemit X60 cores (RVA22 + RVV 1.0 with VLEN=256) and it also fails there. This was compiled with gcc 14.2. The earlier qemu test I did with gcc 15.0 and gcc 13.3. Both fail with VLEN=256. SpacemiT X60 result: % ./libgcrypt-rvv-vlen128-assumption Element-by-element view of out[0..15]: out[ 0] = 10001111 out[ 1] = 10002222 out[ 2] = 10003333 out[ 3] = 10004444 out[ 4] = 00000000 out[ 5] = 00000000 out[ 6] = 00000000 out[ 7] = 00000000 out[ 8] = 20001111 out[ 9] = 20002222 out[10] = 20003333 out[11] = 20004444 out[12] = 00000000 out[13] = 00000000 out[14] = 00000000 out[15] = 00000000 libgcrypt-shaped layout (VLEN=128 assumption): BUG -- AES_CRYPT m4 vl=16 will not find the 4 blocks here Where each loaded m1 register actually lands in g (per RVV intrinsic spec, sub-register N -> elements N*VLMAX_m1 .. (N+1)*VLMAX_m1 - 1): out[0..3] = sub-register 0 (= r0 + r0-tail) ... and so on for sub-registers 1..3 % _______________________________________________ Gcrypt-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
