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.weig...@de.ibm.com
