https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note we do have ad-hoc code in insert_debug_temp_for_var_def dealing with such
situations, but it doesn't trigger here because there is dominator info
available used as indicator that SSA form is up-to-date:
if (!dom_info_available_p (CDI_DOMINATORS))
{
struct walk_stmt_info wi;
memset (&wi, 0, sizeof (wi));
/* When removing blocks without following reverse dominance
order, we may sometimes encounter SSA_NAMEs that have
already been released, referenced in other SSA_DEFs that
we're about to release. Consider:
<bb X>:
v_1 = foo;
<bb Y>:
w_2 = v_1 + bar;
# DEBUG w => w_2
If we deleted BB X first, propagating the value of w_2
won't do us any good. It's too late to recover their
original definition of v_1: when it was deleted, it was
only referenced in other DEFs, it couldn't possibly know
it should have been retained, and propagating every
single DEF just in case it might have to be propagated
into a DEBUG STMT would probably be too wasteful.
When dominator information is not readily available, we
check for and accept some loss of debug information. But
if it is available, there's no excuse for us to remove
blocks in the wrong order, so we don't even check for
dead SSA NAMEs. SSA verification shall catch any
errors. */
if ((!gsi && !gimple_bb (def_stmt))
|| walk_gimple_op (def_stmt, find_released_ssa_name, &wi))
no_value = true;
I'm quite sure we're getting this wrong more often, but only few build
workers ICE on error_mark TREE_TYPE.
