This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.4 fix for PR24950, ICE in operand_subword_force


> 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.

I don't mind that, since it's a fix.

> 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.

I do mind that, since it's not a fix.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]