http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59119
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2013-11-13
CC| |law at redhat dot com
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from Jeffrey A. Law <law at redhat dot com> ---
Thanks Ulrich. I'm pretty sure I know what's going on here. When we remove
statements after the builtin_trap, we remove them in statement order:
;; basic block 3, loop depth 0
;; pred: 2
_8 = (long unsigned int) _6;
memmove (buf_7(D), 0B, _8);
_10 = spec_5(D)->n_prefix;
_11 = (sizetype) _10;
buf_12 = buf_7(D) + _11;
# DEBUG buf => buf_12
In this block we're going to insert a __builtin_trap before the memmove call as
memmove is not allowed to have NULL pointer arguments.
When then proceed to remove the remaining statements in the block starting with
the memmove call proceeding to the end of the block. As we remove statements
with an LHS (such as _11 = ...) we release the SSA name back to the name
manager.
The problem is once released, we're not supposed to touch the names anymore.
But a later remove (say of the statement buf_12 = ... ) may try to insert debug
temps which will look at the RHS of that statement. In particular it'll look
at SSA_NAME 11 which we have already released to the manager.
This should be an easy fix.
