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

[Jan Hubicka]

> > > 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))
> > > 
> 
> I have come to the conclusion that there is a problem with
> GO_IF_LEGITIMATE_ADDRESS on the vax (ie, it shouldn't accept a
> DCmode MEM with the above indexing) since the maximum number
> of bytes that can be moved in a single insn is 8.
Yes, this is the complex type hackery - basically it does the DC modes behind
scene w/o validation from backend splitting it later.
What you need is to figure out from where the subreg is comming and replace
gen_SUBREG by simplify_gen_subreg. That should be enought I guess.

In case simplify_gen_subreg for some purpose refuse to simplify memory in question,
let me know.

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