gcc-3.3 problem with reloading byte into address register on ColdFire

[Peter Barada <peter at baradas dot org>]

I've stumbled across a problem with reload trying to load a byte into
an address register, something legal on m68k, but illegal on ColdFire:

[peter@baradas ice]$ /tmp/m68k-elf-3.3/bin/m68k-elf-gcc -O1 -m5307 -fPIC -S -o ice.s ice.c -da
ice.c: In function `_dtostr':
ice.c:72: error: insn does not satisfy its constraints:
(insn 307 130 131 5 (nil) (set (reg:QI 8 %a0)
        (mem:QI (plus:SI (reg/f:SI 14 %a6)
                (const_int -255 [0xffffff01])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
    (nil))
ice.c:72: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8348
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


ice.c.23.lreg:

(insn 131 130 134 5 0x4001f2c0 (set (subreg:SI (reg/v:QI 41) 0)
        (plus:SI (subreg:SI (reg/v:QI 41) 0)
            (const_int 32 [0x20]))) 100 {*addsi3_5200} (nil)
    (nil))


ice.c.24.greg:

Spilling for insn 131.
Using reg 8 for reload 1

Reloads for insn # 131
Reload 0: ADDR_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
	reload_out_reg: (reg/v:QI 41)
Reload 1: reload_in (QI) = (reg/v:QI 41)
	reload_out (QI) = (reg/v:QI 41)
	ADDR_REGS, RELOAD_OTHER (opnum = 1)
	reload_in_reg: (reg/v:QI 41)
	reload_out_reg: (reg/v:QI 41)
	reload_reg_rtx: (reg:QI 8 %a0)

(insn 307 130 131 5 (nil) (set (reg:QI 8 %a0)
        (mem:QI (plus:SI (reg/f:SI 14 %a6)
                (const_int -255 [0xffffff01])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
    (nil))

(insn 131 307 308 5 0x4001f2c0 (set (reg:SI 8 %a0)
        (plus:SI (reg:SI 8 %a0)
            (const_int 32 [0x20]))) 100 {*addsi3_5200} (nil)
    (nil))



How do I tell gcc that address registers can not hold bytes, but
*only* for ColdFire? 

gcc/config/m68k/m68k.h already has:

/* Given an rtx X being reloaded into a reg required to be
   in class CLASS, return the class of reg to actually use.
   In general this is just CLASS; but on some machines
   in some cases it is preferable to use a more restrictive class.
   On the 68000 series, use a data reg if possible when the
   value is a constant in the range where moveq could be used
   and we ensure that QImodes are reloaded into data regs.  */

#define PREFERRED_RELOAD_CLASS(X,CLASS)  \
  ((GET_CODE (X) == CONST_INT			\
    && (unsigned) (INTVAL (X) + 0x80) < 0x100	\
    && (CLASS) != ADDR_REGS)			\
   ? DATA_REGS					\
   : (GET_MODE (X) == QImode && (CLASS) != ADDR_REGS) \
   ? DATA_REGS					\
   : (GET_CODE (X) == CONST_DOUBLE					\
      && GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT)			\
   ? (TARGET_68881 && (CLASS == FP_REGS || CLASS == DATA_OR_FP_REGS)	\
      ? FP_REGS : NO_REGS)						\
   : (TARGET_PCREL				\
      && (GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST \
	  || GET_CODE (X) == LABEL_REF))	\
   ? ADDR_REGS					\
   : (CLASS))

/* Force QImode output reloads from subregs to be allocated to data regs,
   since QImode stores from address regs are not supported.  We make the
   assumption that if the class is not ADDR_REGS, then it must be a superset
   of DATA_REGS.  */

#define LIMIT_RELOAD_CLASS(MODE, CLASS) \
  (((MODE) == QImode && (CLASS) != ADDR_REGS)	\
   ? DATA_REGS					\
   : (CLASS))


Which I'd expect to prevent this...

I've stumbled onto a variant of this problem before:
http://gcc.gnu.org/ml/gcc/2002-03/msg00146.html

Any information is appreciated...

-- 
Peter Barada
peter@baradas.org