This is the mail archive of the
mailing list for the GCC project.
Re: More general patch for "mips offs > 16bit", (emit_insn/force_operand inconsistencies, expr.c 1.76).
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Subject: Re: More general patch for "mips offs > 16bit", (emit_insn/force_operand inconsistencies, expr.c 1.76).
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Wed, 17 Mar 1999 23:34:19 -0700
- cc: egcs-patches at egcs dot cygnus dot com, pefo at opsycon dot se, jonathan at DSG dot Stanford dot EDU
- Reply-To: law at cygnus dot com
In message <Pine.BSF.4.02A.firstname.lastname@example.org>you write
> On Wed, 10 Mar 1999, Jeffrey A Law wrote:
> The bogus-operand-generating site is the statement preceding
> the patch I sent (i.e. the code below): "temp" is set from a
> call to change_address; to_rtx is "(mem/s:BLK (reg:SI 81))",
> bitpos 2208032 and bitsize 16.
> Now, the inner rtx returned from "change_address" is not always
> valid for input to force_reg. In this case, the return value
> (temp) is "(mem/s:HI (plus:SI (reg:SI 81) (const_int 276004)))".
> Still, force_reg is called with "XEXP(temp, 0)".
> This code was introduced with the 1.75 .. 1.76 change for expr.c.
> Here's the first hunk of that, with comments (the second is similar):
You're missing the point. Debug change_address.
The value returned by change_address should be a valid address for the target
machine. (plus (ref) (large_int)) is not a valid address on a MIPS target.
If change_address actually returns a valid address, then the call to force_reg
should work as expected. The problem is the MIPS port is claiming an address
is valid that is not really valid.
Don't focus on the fact that this worked in 1.75, but not 1.76. That is