PR 13722 candidate fix

Zack Weinberg zack@codesourcery.com
Sat Jan 24 01:35:00 GMT 2004


Jim Wilson <wilson@specifixinc.com> writes:

> On Fri, 2004-01-23 at 00:47, Zack Weinberg wrote:
>> Re-revised patch.
>
> On the REG/SUBREG issue, I was looking at your latest patch.  In the
> full context of the previous patch, I see you already handle most of
> these issues by having a default switch case that aborts.

Yes.  I think there are good /a priori/ reasons to assume that we
won't ever get SUBREGs here, so I think this is adequate.  (A SUBREG
in the operand itself could only be paradoxical, and shouldn't survive
this far; a SUBREG in the MEM expression would either be paradoxical,
and again shouldn't have survived this far, or would take it out of
Pmode and therefore indicate a bug elsewhere.)

> The only real issue I see here is in the POST_MODIFY code where you
> have
> +           if (GET_CODE (XEXP (offset, 1)) == REG)
> ...
> +           else if (INTVAL (XEXP (offset, 1)) < -256 + 8)
> which assumes without checking that the offset is a CONST_INT if it
> isn't a REG.  I put in an abort to see if this ever happens, but I doubt
> that it does.

The theory here was that INTVAL would trigger an RTL checking abort if
offset wasn't a CONST_INT, so there was no need for an explicit
check.  I now remember that RTL checking isn't on by default, so an
explicit check would probably be wise.

> I see you have another modified patch.  I can try this when my current
> build finishes.

I would appreciate that.

zw



More information about the Gcc-patches mailing list