[Bug target/12133] New: Reload abort in simd-3.c

["drow at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12133

           Summary: Reload abort in simd-3.c
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: drow at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-elf

You need to run the testsuite with -mno-apcs-frame -msoft-float to reproduce this
with an arm-elf compiler:
gcc -msoft-float -mno-apcs-frame -S testsuite/gcc.c-torture/compile/simd-3.c -O1

simd-3.c:22: internal compiler error: in change_address_1, at emit-rtl.c:2125
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

The problem is caused by storing the result of the addition in a temporary on
the stack.  With -mno-apcs-frame, the temporary happens to be located at exactly
$sp.  When find_reloads_toplev is called on:

(insn 44 43 45 0 0x40347294 (set (subreg:DF (reg:V2DF 76) 8)
        (reg:DF 0 r0 [82])) 183 {*movdf_soft_insn} (insn_list 33 (insn_list 43
(nil)))
    (expr_list:REG_DEAD (reg:DF 0 r0 [82])
        (nil)))

with call debug_rtx (reg_equiv_mem[76])
(mem:V2DF (reg/f:SI 13 sp) [0 S16 A64])

[instead of (plus (reg fp) (const int -48)) which we get with -mapcs-frame.]

We hit this code:               && (reg_equiv_address[regno] != 0
                   || (reg_equiv_mem[regno] != 0
                       && (! strict_memory_address_p (GET_MODE (x),
                                                      XEXP
(reg_equiv_mem[regno], 0))
                           || ! offsettable_memref_p (reg_equiv_mem[regno])
                           || num_not_at_initial_offset))))

Eventually, offsettable_memref_p calls strict_memory_address_p on:
(plus:SI (reg/f:SI 13 sp)
    (const_int 15 [0xf]))
with mode == QImode.

Here's where we have trouble.  GO_IF_LEGITIMATE_ADDRESS accepts the above
for QImode, but does not accept
(plus:SI (reg/f:SI 13 sp)
    (const_int 8 [0xf]))
for DFmode.  So we abort, because the result is unrecognizable.

I don't see how to handle this.  output_double_move can handle this - it
will output two stores instead of a store-multiple - but presumably accepting
this as legitimate would hurt other generated code.

Is it feasible to allow offsettable_memref_p to vary by mode?  Or should
this be checked somewhere else?