https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> --- So we end up dropping into rs6000_emit_le_vsx_store from gen_movv4si via: if (!BYTES_BIG_ENDIAN && VECTOR_MEM_VSX_P (<MODE>mode) && !TARGET_P9_VECTOR && !gpr_or_gpr_p (operands[0], operands[1]) && (memory_operand (operands[0], <MODE>mode) ^ memory_operand (operands[1], <MODE>mode))) { rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode); DONE; } This is catching the case (during expand) where we have non LE friendly loads/stores and we need to emit permutes with them. In the case where we are ICEing, we actually have a LE friendly Altivec mem: Breakpoint 9, rs6000_emit_le_vsx_store (dest=0x3fffb580c888, source=0x3fffb580ea90, mode=E_V4SImode) at /home/bergner/gcc/gcc-fsf-mainline-pr84264/gcc/config/rs6000/rs6000.c:10357 10357 { (gdb) pr2 dest source (mem/c:V4SI (and:DI (plus:DI (reg:DI 141) (reg:DI 140)) (const_int -16 [0xfffffffffffffff0])) [1 args+0 S16 A128]) (reg:V4SI 142) In this case, we can just emit the store normally and don't need to drop into rs6000_emit_le_vsx_move at all. Guarding the code above to ensure we don't have an Altivec mem via altivec_indexed_or_indirect_operand() fixes the ICE: Index: vector.md =================================================================== --- vector.md (revision 258115) +++ vector.md (working copy) @@ -136,8 +136,10 @@ (define_expand "mov<mode>" && VECTOR_MEM_VSX_P (<MODE>mode) && !TARGET_P9_VECTOR && !gpr_or_gpr_p (operands[0], operands[1]) - && (memory_operand (operands[0], <MODE>mode) - ^ memory_operand (operands[1], <MODE>mode))) + && ((memory_operand (operands[0], <MODE>mode) + && !altivec_indexed_or_indirect_operand(operands[0], <MODE>mode)) + ^ (memory_operand (operands[1], <MODE>mode) + && !altivec_indexed_or_indirect_operand(operands[1], <MODE>mode)))) { rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode); DONE;