Balthasar Biedermann <[EMAIL PROTECTED]> writes: > #0 0x081c5d48 in mark_jump_label_1 (x=0x0, insn=0xb7b77118, in_mem=0 > '\0', is_target=0 '\0') at ../.././gcc/jump.c:987 > #1 0x081c60e0 in mark_jump_label_1 (x=0xb7b70e28, insn=0xb7b77118, > in_mem=0 '\0', is_target=0 '\0') at ../.././gcc/jump.c:1108
Some insn was generated incorrectly: the field of the insn should not be NULL. You are going to have to find out why. This is a bug in your backend. There is no way that we can possibly know what the problem is. > I found out that the RTX which enters mark_jump_label and later causes > the error is a "parallel". That is strange, because a don't use > parallels in my machine description file(*.md) yet. > The parallel RTX is passed to mark_jump_label() and from there to > mark_jump_label_1(). In mark_jump_label_1 in line 1108 it takes XVECEXP > (x, i, j) from the RTX x and the value of this XVECEXP-expression is > null. So I thik the error occures either because the RTX is not valid or > because VECEXP dont't work right or because the variables i and j are > too big/wrong. The value of i goes from GET_RTX_LENGTH (code), where > code is GET_CODE(RTX x), to 0. j goes from XVECLEN (x, i) - 1 to 0. Yes. The RTX is not valid. > Can I influence one of these things with the Target Makros or the > Machine Description? Yes. Look to find out where that PARALLEL was created, and why. Use debug_rtx to find the insn uid. Set a breakpoint on, e.g., make_jump_insn_raw and find out what is creating that particular insn. Writing your own gcc backend requires digging into the code and figuring it out. It's not simple. We can't answer precise and detailed questions about how it is supposed to work, but we can't help you debug it. Ian
