i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
> ../include
>          varasm.c
> (insn 117 429 118 7 (parallel [
>             (set (reg:SI 64)
>                 (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21 
> virtual-stack-vars)
> 
>                             (const_int 456 [0x1c8])) [232 value+0 S196 A64])
>                     (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
>                             (const_int 8 [0x8])) [0 A8])))
>             (use (const_int 196 [0xc4]))
>         ]) -1 (nil)
>     (nil))
> varasm.c: In function `force_const_mem':
> varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
> at function.c:3767

OK, so what goes on here is that GCC attempts to replace the "virtual"
register 21 (virtual-stack-vars) with some real register, that is
frame pointer + STARTING_FRAME_OFFSET.  It seems for the i370 port,
this should resolve to
  register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size

Overall, the middle-end would therefore replace "reg 21 + 456" with 
"reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
+ current_function_outgoing_args_size.

It will then re-process the insn pattern constraints to verify that the
resulting insn is still valid.  At this stage, it appears we're running
into the above error.  I'm not quite sure why this would be case, this
will require some further debugging why the insn was not recognized ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com