On 16 November 2007 00:01, Jim Wilson wrote:
> Michael_fogel wrote:
>> (ior:SI (subreg:SI (mem/s:QI (reg/f:SI 1250) [0
>> <variable>.flags+0 S1 A32]) 0)
>
> See register_operand and general_operand in recog.c. (SUBREG (MEM)) is
> accepted by register_operand if INSN_SCHEDULING is not defined, for
> historical reasons. This is something that should be fixed some day.
>
> INSN_SCHEDULING is defined if you have any of the instruction scheduling
> related patterns in your md file. If this is a new port, and you
> haven't tried to add instruction scheduling support, then
> INSN_SCHEDULING won't be defined yet.
>
> Anyways, this means that the RTL is correct, and we expect reload to fix
> it. The error from gen_reg_rtx implies that reload is failing, perhaps
> because of a bug in your port that doesn't handle (SUBREG (MEM)) correctly.
>
> There are other legitimate cases where (SUBREG (MEM)) can occur during
> reload, when you have a subreg of an pseudo that did not get allocated
> to a hard register for instance, so even if register_operand and
> general_operand are changed, you still need to find and fix the bug in
> your port.
First places to look would be GO_IF_LEGITIMATE_ADDRESS and
REG_OK_FOR_BASE_P, wouldn't they? Particularly in conjunction with
REG_OK_STRICT.
cheers,
DaveK
--
Can't think of a witty .sigline today....
