Opening this up to the gcc public, since I appear to be unable to get
this to work right.
Still no luck defining a working IRA_COVER_CLASSES for m32c. My
latest attempt:
#define IRA_COVER_CLASSES \
{ \
HC_REGS, MEM_REGS, LIM_REG_CLASSES \
}
(effectively GENERAL_REGS (which I also tried), but MEM_REGS regs are
implemented as memory locations, so I had tried without them) results
in this build failure in newlib:
m32c-elf-gcc -B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/ -isystem
/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/targ-include -isystem
/greed/dj/m32c/newlib/src/newlib/libc/include
-B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/libgloss/m32c
-L/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/libgloss/libnosys
-L/greed/dj/m32c/newlib/src/libgloss/m32c -mcpu=m32cm
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.16.0\" -DPACKAGE_STRING=\"newlib\ 1.16.0\"
-DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../src/newlib/libc/stdlib -Os
-DPREFER_SIZE_OVER_SPEED -DABORT_PROVIDED -DSMALL_MEMORY
-DMISSING_SYSCALL_NAMES -fno-builtin -g -O2 -mcpu=m32cm
-DINTERNAL_NEWLIB -DDEFINE_MALLOC -c
../../../../../../src/newlib/libc/stdlib/mallocr.c -o lib_a-mallocr.o
../../../../../../src/newlib/libc/stdlib/mallocr.c: In function '_malloc_r':
../../../../../../src/newlib/libc/stdlib/mallocr.c:2588: error: unable to find
a register to spill in class 'HL_REGS'
../../../../../../src/newlib/libc/stdlib/mallocr.c:2588: error: this is the
insn:
(insn 661 660 662 101 ../../../../../../src/newlib/libc/stdlib/mallocr.c:2194
(set (reg:HI 0 r0 [262])
(and:HI (subreg:HI (reg:PSI 5 a1 [258]) 0)
(const_int 127 [0x7f]))) 26 {andhi3_24} (expr_list:REG_DEAD
(reg:PSI 5 a1 [258])
(nil)))
../../../../../../src/newlib/libc/stdlib/mallocr.c:2588: internal compiler
error: in spill_failure, at reload1.c:2093
As I've said before, m32c is probably a "worst case" scenario for gcc
as it has not one, not two, not even three, but FOUR different types
of registers (8/16 bit general, 16 bit only general, 24 bit address
registers, and control (incl $fp) registers), and only a small number
(2) of each.
I'm beginning to suspect that anyone doing ANYTHING with register
allocation or reload should include m32c in their testing, as it seems
to have broken every time those got changed.
Vlad, could you try your hand at this? Please? :-)
DJ
