https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:dc386b020869ad0095cf58f8c76a40ea457e7a2c commit r11-8789-gdc386b020869ad0095cf58f8c76a40ea457e7a2c Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Jul 20 16:41:29 2021 +0200 rs6000: Fix up easy_vector_constant_msb handling [PR101384] The following gcc.dg/pr101384.c testcase is miscompiled on powerpc64le-linux. easy_altivec_constant has code to try construct vector constants with different element sizes, perhaps different from CONST_VECTOR's mode. But as written, that works fine for vspltis[bhw] cases, but not for the vspltisw x,-1; vsl[bhw] x,x,x case, because that creates always a V16QImode, V8HImode or V4SImode constant containing broadcasted constant with just the MSB set. The vspltis_constant function etc. expects the vspltis[bhw] instructions where the small [-16..15] or even [-32..30] constant is sign-extended to the remaining step bytes, but that is not the case for the 0x80...00 constants, with step 1 we can't handle e.g. { 0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff, 0x80, 0xff, 0xff, 0xff } vectors but do want to handle e.g. { 0, 0, 0, 0x80, 0, 0, 0, 0x80, 0, 0, 0, 0x80, 0, 0, 0, 0x80 } and similarly with copies 1 we do want to handle e.g. { 0x80808080, 0x80808080, 0x80808080, 0x80808080 }. This is a simpler version of the fix for backports, which limits the EASY_VECTOR_MSB case matching to step == 1 && copies == 1, because that is the only case the splitter handles correctly. 2021-07-20 Jakub Jelinek <ja...@redhat.com> PR target/101384 * config/rs6000/rs6000.c (vspltis_constant): Accept EASY_VECTOR_MSB only if step and copies are equal to 1. * gcc.dg/pr101384.c: New test.
