This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


For following test-case:

typedef double v4df __attribute__ ((vector_size (32)));
void foo(v4df);

main ()
  volatile v4df x1;
  x1 = (v4df) { 10.0, 20.0, 30.0, 40.0 };
  foo (x1);
  return 0;

Compiling with -msve-vector-bits=256, the compiler goes into infinite
recursion and eventually segfaults due to stack overflow.

This happens during expansion of:
  x1.0_1 ={v} x1;

aarch64_expand_sve_mem_move calls aarch64_emit_sve_pred_move with
dest = (reg:VNx2DF 93) and
src = (mem/u/c:VNx2DF
           (plus:DI (reg/f:DI 94) (const_int 32 [0x20])) [0  S32 A128])

aarch64_emit_sve_pred_move calls expand_insn with above ops.
Eventually we hit EXPAND_INPUT case in maybe_legitimize_operand for
src (opno == 2)

Since the operand is marked with volatile, and volatile_ok is set to false,
insn_operand_matches return false and we call:
      op->value = copy_to_mode_reg (mode, op->value);

copy_to_mode_reg however, creates a fresh register and calls emit_move_insn:
rtx temp = gen_reg_rtx (mode);
if (x != temp)
    emit_move_insn (temp, x);

and we again end up in aarch64_emit_sve_pred_move, with dest assigned
the new register and src remaining unchanged, and thus the cycle continues.

As suggested by Richard, the attached patch temporarily sets volatile_ok to true
using RAII class volatile_ok_temp in aarch64_emit_sve_pred_move which
avoids the recursion.

Bootstrap + tested on x86_64-unknown-linux-gnu, aarch64-linux-gnu.
Cross-testing with SVE in progress.
OK to commit ?


Attachment: pr90723-2.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]