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