https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127189
Bug ID: 127189
Summary: rs6000: Few vsx-{load,store}-element* tests fail in
power10 BE target
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: testsuite-fail
Severity: normal
Priority: P3
Component: testsuite
Assignee: avinashd at gcc dot gnu.org
Reporter: avinashd at gcc dot gnu.org
CC: jskumari at gcc dot gnu.org, meissner at gcc dot gnu.org
Blocks: 125965
Target Milestone: ---
Target: powerpc64, rs6000
The following tests:
gcc.target/powerpc/vsx-load-element-extend-int.c
gcc.target/powerpc/vsx-load-element-extend-longlong.c
gcc.target/powerpc/vsx-load-element-extend-short.c
gcc.target/powerpc/vsx-store-element-truncate-longlong.c
Fail on power10 BE target.
The vsx-load tests use the intrinsic vec_xl_sext/zext. The inputs in these
tests are given as character byte array but we load them as int/long
long/short. Due to which we see reversed outputs in BE target.
Suggested solution: Use appropriate typed arrays for inputs in each test.
The vsx-store fails only for longlong, but passes for char,int,short. Since the
offset that is being modified is larger than the type size for them, but in
case of long long, the offset is shorter. Example,
We have input (128 bit)
80 00 00 00 00 00 00 00 fe dc ba 98 76 54 32 17
in register if loaded as __int128 type, the order of bytes is same in both LE
and BE.
lets say first 12 bytes of vsbuffer is layed out like this (showing zeroed out
12 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Now we store it to memory using
test_signed_store (store_this_s[i], 4*i, vsbuffer);
say i = 1,
then the contents of vsbuffer in BE (based on stxvrdx instruction)
00 00 00 00 fe dc ba 98 | 76 54 32 17 00 00 00 00
and in LE it will be
00 00 00 00 17 32 54 76 | 98 ba dc fe 00 00 00 00
now when we load this as address as a double word vector the register contents
in LE:
76 54 32 17 00 00 00 00 | 00 00 00 00 fe dc ba 98
(only the order of elements is reversed)
but in BE it would be
00 00 00 00 fe dc ba 98 | 76 54 32 17 00 00 00 00
Causing different expected results in LE and BE.
Suggested fix would be to modify the test to not use offset that is less than
size of the type and unaligned.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125965
[Bug 125965] rs6000: Few Power10 big-endian tests fail due to endian-dependent
expected values
