Bug 12133 - Reload abort in simd-3.c
Summary: Reload abort in simd-3.c
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, patch
Depends on:
Blocks:
 
Reported: 2003-09-02 16:30 UTC by Daniel Jacobowitz
Modified: 2005-10-14 01:23 UTC (History)
3 users (show)

See Also:
Host: i386-pc-linux-gnu
Target: arm-elf
Build: i386-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2003-12-19 15:35:33


Attachments
vdfmode.patch (420 bytes, text/plain)
2003-12-19 15:34 UTC, Richard Earnshaw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Jacobowitz 2003-09-02 16:30:52 UTC
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?
Comment 1 Richard Earnshaw 2003-12-19 15:34:03 UTC
Subject: Re:  Reload abort in simd-3.c

This is just an idea on how we might prevent this.  It does fix the abort, 
but I haven't had time to test it much.

The patch works by using adjust_address_nv to generate a candidate 
replacement address and then tries to validate that specific address (and 
mode) rather than trying to guess by using offsettable_address_p, which 
clearly doesn't work in this case.

R.


Comment 2 Richard Earnshaw 2003-12-19 15:34:06 UTC
Created attachment 5348 [details]
vdfmode.patch
Comment 3 Dara Hazeghi 2004-01-23 20:18:03 UTC
Reconfirmed on 3.3-branch/mainline. Richard, are you planning to submit the patch?
Comment 4 GCC Commits 2004-07-09 10:06:16 UTC
Subject: Bug 12133

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rearnsha@gcc.gnu.org	2004-07-09 10:06:03

Modified files:
	gcc            : ChangeLog 
	gcc/config/arm : arm.c 

Log message:
	PR target/12133
	* arm.c (arm_legitimate_index_p) Allow DFmode for soft-float
	and DImode to use +/-4k offset.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.4417&r2=2.4418
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gcc&r1=1.374&r2=1.375

Comment 5 Richard Earnshaw 2004-07-09 10:29:54 UTC
Here's an explanation of why I've fixed it this way.

http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00926.html
Comment 6 Flash Sheridan 2005-10-14 01:23:06 UTC
PalmSource bug 110648