How bugs like this were not hit earlier, I'll never understand :-)
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.
I fully understand that delete_related_insns() is a deprecated
interface, and the "right" way to do this is to use delete_insn() and
perform cfg cleanups afterwards. But fixing reorg to no longer use
delete_related_insns() is a rather large task, and certainly outside
the scope of fixing this bug in 4.7.
Ok for mainline and 4.7 branch?
* jump.c (delete_related_insns): If we remove a CALL, make sure
we delete it's NOTE_INSN_CALL_ARG_LOCATION note too.
diff --git a/gcc/jump.c b/gcc/jump.c
index 52cbbca..d49b58e 100644
--- a/gcc/jump.c
+++ b/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. */
