https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127274
--- Comment #2 from Jeevitha <jeevitha at gcc dot gnu.org> ---
For sse2_test_movmskpd_1.c, _mm_movemask_pd() uses vec_extractm() on Power10:
Explained vec_extractm() for byte elements. Similarly, we can consider the case
for double-word elements, as explained in [Bug 127148, Comment 1].
#ifdef _ARCH_PWR10
return vec_extractm ((__v2du) __A);
#else
...
#endif
For the testcase:
double source[2] = {1.234, -2234.23};
the input values are:
source[0] = 0x3ff3be76c8b43958 -> sign bit = 0
source[1] = 0xc0a17475c28f5c29 -> sign bit = 1
On Power10 BE, the vector register contains:
v0 = 0x3ff3be76c8b43958c0a17475c28f5c29
and vextractdm returns:
result = 01b
On Power10 LE, the vector register has the opposite byte ordering:
v0 = 0xc0a17475c28f5c293ff3be76c8b43958
and vextractdm returns:
result = 10b
Therefore, the same two sign bits produce different values on BE and LE:
LE: 10b = 0x2
BE: 01b = 0x1
However, _mm_movemask_pd() requires the same result regardless of target
endianness. For these inputs, the expected result is 0x2.
Thus, on Power10 BE, vec_extractm() produces the bits in the opposite order
semantics, resulting in the testcase failure.
The P9 BE implementation does not fail because it uses the existing vbpermq
path with a BE-specific permutation mask, which produces the required bit
ordering.
