Fix var tracking ICE due to reorg.
If during reorg we delete a code label, and as a result we decide to delete all the code following that label, we hit this condition in jump.c:delete_related_insns(): if (was_code_label && prev && BARRIER_P (prev)) which passes and then we proceed to delete insns until we hit a non-deleted code label. During this traversal, we can end up deleting a CALL, but in doing so we will leave the var tracking note for the call arguments around. Later in dwarf2_var_location() we will ICE, because we can't find the CALL when we search backwards for it. The note searching scheme in the fix below is cribbed from code in try_split() which has to handle a similar problem. gcc/ * jump.c (delete_related_insns): If we remove a CALL, make sure we delete it's NOTE_INSN_CALL_ARG_LOCATION note too. From-SVN: r187606
This commit is contained in:
parent
e10f759e19
commit
0e2b0f75cc
|
@ -1,3 +1,8 @@
|
|||
2012-05-16 David S. Miller <davem@davemloft.net>
|
||||
|
||||
* jump.c (delete_related_insns): If we remove a CALL, make sure
|
||||
we delete it's NOTE_INSN_CALL_ARG_LOCATION note too.
|
||||
|
||||
2012-05-16 Bill Schmidt <wschmidt@linux.vnet.ibm.com>
|
||||
|
||||
PR tree-optimization/53217
|
||||
|
|
20
gcc/jump.c
20
gcc/jump.c
|
@ -1252,6 +1252,26 @@ delete_related_insns (rtx insn)
|
|||
if (next != 0 && BARRIER_P (next))
|
||||
delete_insn (next);
|
||||
|
||||
/* If this is a call, then we have to remove the var tracking note
|
||||
for the call arguments. */
|
||||
|
||||
if (CALL_P (insn)
|
||||
|| (NONJUMP_INSN_P (insn)
|
||||
&& GET_CODE (PATTERN (insn)) == SEQUENCE
|
||||
&& CALL_P (XVECEXP (PATTERN (insn), 0, 0))))
|
||||
{
|
||||
rtx p = insn;
|
||||
|
||||
for (p = NEXT_INSN (p);
|
||||
p && NOTE_P (p);
|
||||
p = NEXT_INSN (p))
|
||||
if (NOTE_KIND (p) == NOTE_INSN_CALL_ARG_LOCATION)
|
||||
{
|
||||
remove_insn (p);
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
/* If deleting a jump, decrement the count of the label,
|
||||
and delete the label if it is now unused. */
|
||||
|
||||
|
|
Loading…
Reference in New Issue