https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109069
Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Vector truncation test |[12/13 Regression] Vector |program produces incorrect |truncation test program |result on big-endian |produces incorrect result |powerpc64-linux-gnu with |since |-mcpu=power10 -O2 |r12-6537-g080a06fcb076b3 Known to work| |11.3.0 --- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> --- One test case can be: #include <altivec.h> __attribute__ ((noipa)) vector signed int test () { vector signed int v = {-16, -16, -16, -16}; vector signed int res = vec_sld (v, v, 3); return res; } int main () { vector signed int res = test (); if (res[0] != 0xf0ffffff) __builtin_abort (); return 0; } It fails on Power7,8,9,10. It starts to fail from r12-6537-g080a06fcb076b3, when the two input operands are the same, it's only safe to optimize it into a vector move no matter what's the shift count is that the given vector is a const vec_duplicate and the duplicated element is affordable in a byte. The culprit commit is incorrect to use easy_vector_constant as predicate, which just guards those vector constants without memory loading. The reason why the reporter only saw this on Power10 is that the given constant 0xFA578D00u can only satisfy "easy_vector_constant" till power10. The constructed test case above adopts one constant which can be built with vspltisw, then we can easily see the failure.