Re: restricted addressing modes in ColdFire FPU.

[Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>]

I'm in the midst of adding support for the coldfire v4e FPU to
gcc-2.95.3, and I'm running into a problem.  THe FPU in coldfire can
not deal with absolute addresses, so I've modified the two macros
GO_IF_LEGITMATE_ADDRESS and LEGITIMIZE_ADDRESS to regect absolute
addresses if the MODE_CLASS is float.  I haven't fleshed out all of
the FPU yet, but it seems to do the trick.  Unfortunately I'm running
into the problem where I get an internal compiler error:

../printset/pscalibration.c: In function `calculate_calibrate_array_ob':
../printset/pscalibration.c:262: Internal compiler error in `gen_reg_rtx', at emit-rtl.c:557
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

and in gdb the backtrace is:

(gdb) where 13
#0  exit (status=33) at exit.c:40
#1  0x08049a9e in fatal ()
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/toplev.c:1954
#2  0x0809e140 in gen_reg_rtx (mode=SImode)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/emit-rtl.c:557
#3  0x0808c853 in force_reg (mode=SImode, x=0x83101e0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/explow.c:692
#4  0x0808c53f in memory_address (mode=DFmode, x=0x83101e0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/explow.c:515
#5  0x0809f392 in change_address (memref=0x83101e8, mode=DFmode, 
    addr=0x83101e0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/emit-rtl.c:1622
#6  0x081511dd in gen_movdf (operand0=0x82f6908, operand1=0x81de510)
    at insn-emit.c:779
#7  0x080733c1 in emit_move_insn_1 (x=0x82f6908, y=0x81de510)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/expr.c:2641
#8  0x080921e3 in gen_move_insn (x=0x82f6908, y=0x81de510)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/optabs.c:3801
#9  0x08112101 in scan_one_insn (insn=0x82f6920, pass=0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/regclass.c:847
#10 0x081124bc in regclass (f=0x82e617c, nregs=323)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/regclass.c:1039
#11 0x0804c644 in rest_of_compilation (decl=0x82e71f4)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/toplev.c:4160
#12 0x0816fae9 in finish_function (nested=0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-2.95.3/gcc/c-decl.c:7270

The operands in gen_movdf are:

(gdb) fra 6
#6  0x081511dd in gen_movdf (operand0=0x82f6908, operand1=0x81de510)
    at insn-emit.c:779
(gdb) call debug_rtx(operand0)

(reg:DF 204)
(gdb) call debug_rtx(operand1)

(mem/u:DF (symbol_ref/u:SI ("*.LC11")) 0)
(gdb) 


And the code in movdf pattern looks like:

(define_expand "movdf"
  [(set (match_operand:DF 0 "nonimmediate_operand" "")
	(match_operand:DF 1 "nonimmediate_operand" ""))]
  ""
  "
{
  if (TARGET_FPU_V4E) {
    /* The ColdFire FPU can't deal with absolute addresses or double
     * constants, so push it to memory */
    if (CONSTANT_P (operands[1])) {
      operands[1] = force_const_mem(DFmode, operands[1]);
      if (! memory_address_p (DFmode, XEXP (operands[1], 0))
	  && ! reload_in_progress)
	operands[1] = change_address (operands[1], DFmode,
				      XEXP (operands[1], 0));
    }
  }
}")


I'd have thourhg that reload_in_progress would have been enough to
prevent the creation of new RTL by movdf, but reload_in_progress is
zero.  Does anybody have an idea how I can get around this problem?
Any help would be appreciated. Thanks!

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)