Except if I'm mistaken, force_reg will generally call gen_reg_rtx which does check for those two flags internally (via can_create_pseudo_p). So you should not have that error in this case.
I suggest you use a debug_rtx on the operand that's a problem, and first check if gen_reg_rtx is used to create it. If that's the case, you can use gdb to trace when it's called, get a backtrace and work from there. Jc On Wed, May 13, 2009 at 11:54 PM, daniel tian <daniel.xnt...@gmail.com> wrote: > Thank you for your advice. > > Yes. I checked the MD file and relative machine.h/.c, there are some > places which call the ''force_reg' unconditionally. I modified the it > in "movm" insn pattern, the error still exists. And I also check the > mips/arm, they also call 'force_reg' unconditional in some places. > > Anything I missed? > > 2009/5/13 Dave Korn <dave.korn.cyg...@googlemail.com>: >> daniel tian wrote: >>> I have ported gcc4.0.2 to 32bit RISC chip. But internal compiler >>> error happened: in reload_combine_note_use, at postreload.c:1093 . I >>> tracked the code with insight. error occurred in "CASE REG", when the >>> register number is larger than FIRST_PSEUDO_REGISTER. Does this mean >>> the reload register allocation failed? What I know is that there is >>> no pseudo register used after reload completed (Is this right?). >> >> Yes, this is correct. >> >>> Can anyone give me some advice? >> >> It is most likely one of the expanders or other patterns in your MD file is >> unconditionally calling a function such as force_reg() without checking the >> reload_completed / reload_in_progress flags. If this pattern gets invoked >> post-reload, that will allocate a pseudo and then fail later. >> >> cheers, >> DaveK >> >> >> >
