This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: 3.4 fix for PR24950, ICE in operand_subword_force
On Tue, Nov 22, 2005 at 02:59:30PM +0100, Eric Botcazou wrote:
> > In order to fix this PR on 3.4, I need to backport some other
> > patches. Well, strictly speaking, rth's cleanup patch isn't really
> > necessary, but it's much nicer to keep the code like gcc-4 and not too
> > hard to verify that op0 is never a SUBREG so the "Severe Tire Damage"
> > can't happen.
>
> Please be very conservative with the 3.4 branch at this point, given that it
> won't probably get much testing as it is now the _4th_ active branch.
I think this is a safe patch. Dale's patch does two things:
1) In one particular piece of code, adjust_address is always called on a
MEM whereas before the call only happened on a mode change. This
fixed a bug where an offset was ignored. I think you'll agree that
calling adjust_address unnecessarily (ie. when offset is zero) is
safe.
2) Two places in extract_bit_field now don't try to use extv/extzv for
a clearly incorrect situation where the size of the field is larger
than the reg used. My tweak to store_bit_field is the corresponding
case for insv.
That leaves rth's patch. I claim that
- if (GET_CODE (op0) == SUBREG)
- {
- if (GET_MODE (SUBREG_REG (op0)) == fieldmode
- || GET_MODE_CLASS (fieldmode) == MODE_INT
- || GET_MODE_CLASS (fieldmode) == MODE_PARTIAL_INT)
- op0 = SUBREG_REG (op0);
- else
- /* Else we've got some float mode source being extracted into
- a different float mode destination -- this combination of
- subregs results in Severe Tire Damage. */
- abort ();
- }
is dead code. Easily verified by seeing that no assignments to op0
occur after SUBREGs are stripped out earlier. The other part to rth's
patch is replacing gen_rtx_SUBREG with simplify_gen_subreg. Again, I
think you'll agree that this is safe, in fact, more robust.
--
Alan Modra
IBM OzLabs - Linux Technology Centre