Re: Question regarding ICE in instantiate_virtual_regs_1, at function.c:3880

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> I am seeing a number of ICEs in the testsuite in instantiate_virtual_regs_1,
> at function.c:3880, on vax-dec-ultrix4.3 with the main.  The first one that
> I looked at occurs on this insn in gcc.c-torture/compile/991213-1.c:
> 
> (insn 22 21 23 (set (mem/f:DF (plus:SI (reg/f:SI 17 virtual-stack-vars)
>                 (const_int -20 [0xffffffec])) [0 arg+8 S8 A64])
> 	(subreg:DF (mem:DC (plus:SI (mult:SI (reg:SI 21)
> 			(const_int 16 [0x10]))
> 		    (mem/f:SI (reg/f:SI 16 virtual-incoming-args) [0 t+0 S4 A32])) [0 S16 A32]) 8)) -1 (nil)
>    (nil))
> 
> It appears that instantiate_virtual_regs_1 ICEs because general_operand
> (see recog.c:966) doesn't allow a SUBREG with a nonzero SUBREG_BYTE and
> this causes the first instantiation to fail.  Should this insn have been
> created in the first place if there is this limitation on SUBREG MEMs?

I see that the change to general_operand to prohibit nonzero subreg bytes
was made last last May to fix a "not so trivial powerpc regression"
<http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01309.html>.  In this
message, there is mention of being less aggressive and verifying if
offsetted memory will match.  On the otherhand, Richard suggested that
it would be better not to create these subregs in the first place.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)