Following code snippet ICEs: $ cat ice.ii void _setjmp (); void a (unsigned long *); void b () { for (;;) { _setjmp (); unsigned long args[9]{}; a (args); } } $ ./xgcc -B. ice.ii -O1 -fstack-protector-strong -c during RTL pass: reload ice.ii: In function ‘void b()’: ice.ii:12:1: internal compiler error: in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 } ^ 0x10e2dd6 rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode) ../../gcc/config/rs6000/rs6000.c:10367 0x12b5e68 gen_movv4si(rtx_def*, rtx_def*) ../../gcc/config/rs6000/vector.md:142 0xa1e514 insn_gen_fn::operator()(rtx_def*, rtx_def*) const ../../gcc/recog.h:301 0xa1e514 emit_move_insn_1(rtx_def*, rtx_def*) ../../gcc/expr.c:3661 0xa1e8ce emit_move_insn(rtx_def*, rtx_def*) ../../gcc/expr.c:3757 0xbe3422 lra_emit_move(rtx_def*, rtx_def*) ../../gcc/lra.c:497 0xbfb8c4 curr_insn_transform ../../gcc/lra-constraints.c:4297 0xbfd137 lra_constraints(bool) ../../gcc/lra-constraints.c:4883 0xbe6864 lra(_IO_FILE*) ../../gcc/lra.c:2410 0xb9a821 do_reload ../../gcc/ira.c:5465 0xb9a821 execute ../../gcc/ira.c:5649 Happens both on native and x86 cross compiler.
Confirmed. Needs -mlittle, -fstack-protector=strong, any -On with n > 0.
It ICEs on gcc_assert (!lra_in_progress && !reload_completed); but this is called from the movv4si expander, and that is something LRA is allowed to use.
Perhaps related to PR84499.
*** Bug 84499 has been marked as a duplicate of this bug. ***
I'm looking into this.
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;
Author: bergner Date: Mon Mar 5 15:52:11 2018 New Revision: 258251 URL: https://gcc.gnu.org/viewcvs?rev=258251&root=gcc&view=rev Log: gcc/ PR target/84264 * config/rs6000/vector.md (mov<mode>): Disallow altivec memory operands. gcc/testsuite/ PR target/84264 * g++.dg/pr84264.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr84264.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/vector.md trunk/gcc/testsuite/ChangeLog
Fixed on trunk.