https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89892
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-debug
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-04-01
CC| |aoliva at gcc dot gnu.org
Version|unknown |9.0
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. The issue is we end up with
<bb 6> [local count: 14598062]:
# DEBUG BEGIN_STMT
# DEBUG i => 0
# DEBUG BEGIN_STMT
# DEBUG d => 1
goto <bb 9>; [100.00%]
as a forwarder block which CFG cleanup is about to remove. But both
single predecessor and successor edges are critical so we cannot move
the debug stmts. Instead we removed them...
Conservatively we'd have to still move them but instead of inserting
i => 0 we'd have to insert i => NULL, possibly trading debug info
quality in the predecessor/successor for debug info correctness.
As said elsewhere having debug stmts on edges might be a solution to this...
We could also in general avoid removing forwarders connecting two blocks
we could not move debug stmts to (but we'd have to do this irrespective
of their presence). The same issue likely exists on RTL where not
eliminating such forwarder might become costly (unless we can convince us BB
reorder can fixup things so no extra jump will occur with/without such
forwarder).
In this particular case liveness analysis could tell us moving the i => 0
to the successor is OK and moving the d association to the predecessor
is as well (because it already exists there). But that's something we
generally do not want to do (in CFG cleanup anyways).
IIRC I've seen this forwarder-removal in a duplicate bug.
tree_forwarder_block_p explicitely spells out the issue:
/* ??? For now, hope there's a corresponding debug
assignment at the destination. */
case GIMPLE_DEBUG:
break;
