| Message ID | 52F12746.6050702@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 02/04/14 10:45, nick clifton wrote: > Hi Jeff, > >> But how/why did an extended register get selected to begin with? > > It happens in reload.c:find_valid_class(). > >> HARD_REGNO_MODE_OK and other macros/hooks ought to be preventing this >> relatively early. > > Ah - and that is the problem. mn10300_hard_regno_mode_ok is allowing > extended registers to match some classes even in MN10300. > > So how about the patch below ? This also allows the libstdc++-v3 > library to be built. > > Cheers > Nick > > gcc/ChangeLog > 2014-02-04 Nick Clifton <nickc@redhat.com> > > * config/mn10300/mn10300.c (mn10300_hard_regno_mode_ok): Do not > accept extended registers in any mode when compiling for the > MN10300. This is fine. I'm assuming that insn predicate checks prevent similar situations from occurring with FP_REGS & FP_ACC_REGS. ie, patterns with constraints which allow those registers are conditional on TARGET_AM33. Jeff
Index: gcc/config/mn10300/mn10300.c =================================================================== --- gcc/config/mn10300/mn10300.c (revision 207452) +++ gcc/config/mn10300/mn10300.c (working copy) @@ -2614,7 +2612,10 @@ || REGNO_REG_CLASS (regno) == FP_ACC_REGS) /* Do not store integer values in FP registers. */ return GET_MODE_CLASS (mode) == MODE_FLOAT && ((regno & 1) == 0); - + + if (! TARGET_AM33 && REGNO_REG_CLASS (regno) == EXTENDED_REGS) + return false; + if (((regno) & 1) == 0 || GET_MODE_SIZE (mode) == 4) return true;