[Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload
------- Additional Comments From zack at codesourcery dot com 2004-01-22 20:20 -------
Subject: Re: PR 13722 candidate fix
[Note corrected bug number. 13722, not 13772.]
Richard Henderson <rth@redhat.com> writes:
> On Thu, Jan 22, 2004 at 02:07:12PM +0100, Andreas Schwab wrote:
>> (mem/s:TI (post_modify:DI (reg/f:DI 36 loc4 [400])
>> (plus:DI (reg/f:DI 36 loc4 [400])
>> (const_int 8 [0x8]))) [4 opt__R47s+0 S16 A128])
>
> Yep, looking at the patch, I was about to remind Zack that
> (1) post-modify can take registers as well as constants, and
> (2) you have to check for overflowing the 9-bit post-modify
> constant.
That shouldn't be hard... I suppose the thing to do is emit adddi3
instructions to fix up, if either condition is true.
> Hum, and, actually, that post-modify seems very improbable.
> addr += addr? There's sure to be a typo somewhere.
Okay, what is the form of a post_modify expression supposed to be?
This is coming from
switch (base) {
...
case POST_MODIFY:
/* Extract and adjust the modification. */
offset = XEXP (base, 1);
base = XEXP (base, 0);
out[0] = change_address (in, DImode,
gen_rtx_POST_INC (Pmode, base));
out[1] = change_address (in, DImode,
gen_rtx_POST_MODIFY
(Pmode, base, plus_constant (offset, -8)));
break;
and it sure *looks* consistent with what it says in the manual about
the post_modify RTL, which gives
(mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42)
(reg:SI 48))))
as an exemplar.
(Still looking for a clue about the differences among change_address,
adjust_address, offset_address, etc.)
zw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: