https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #22 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- The most suspicious thing I see in r224221 is following the gap adjustment: vect__39.29_261 = REALIGN_LOAD <vect__39.26_282, vect__39.28_264, vect__39.18_18>; vectp_s.20_260 = vectp_s.20_278 + 18446744073709551560; vect__39.30_247 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0 }>; vect__39.31_246 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0 }>; vect__39.32_243 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0 }>; vect__39.33_242 = VEC_PERM_EXPR <vect__39.23_1, vect__39.25_297, { 0, 0, 0, 0 }>; _39 = *_38[1]; vect__40.34_229 = VEC_PACK_TRUNC_EXPR <vect__39.30_247, vect__39.31_246>; vect__40.34_228 = VEC_PACK_TRUNC_EXPR <vect__39.32_243, vect__39.33_242>; _40 = (short int) _39; Instead of interleaving results from the two vectors, this is splatting the first element of one of them. Compare the code from r224220: vect__39.61_161 = REALIGN_LOAD <vect__39.58_251, vect__39.60_179, vect__39.50_259>; vect_perm_even_143 = VEC_PERM_EXPR <vect__39.59_233, vect__39.61_161, { 0, 2, 4, 6 }>; vect_perm_odd_125 = VEC_PERM_EXPR <vect__39.59_233, vect__39.61_161, { 1, 3, 5, 7 }>; _39 = *_38[1]; vect__40.62_107 = VEC_PACK_TRUNC_EXPR <vect_perm_even_43, vect_perm_even_143>; _40 = (short int) _39; I walked through the code enough to see that SLP_TREE_LOAD_PERMUTATION for the SLP tree was just zeros, presumably uninitialized, when read in tree-vect-slp.c:vect_transform_slp_perm_load. But I don't know enough about this code to go further with this tonight.