internal compiler error: in reload_combine_note_use, at postreload.c:1093

[Jean Christophe Beyler]

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.xntian@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.cygwin@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
>>
>>
>>
>