https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-08-21
CC| |jakub at gcc dot gnu.org
Target Milestone|--- |5.0
Summary|ICE with LTO on valid code |[5 Regression] ICE with LTO
|on x86_64-linux-gnu |on valid code on
| |x86_64-linux-gnu
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interesting - we have a gimple_assign in the BBs PHI sequence after the first
reassoc pass, created via
static bool
update_range_test (struct range_entry *range, struct range_entry *otherrange,
unsigned int count, enum tree_code opcode,
vec<operand_entry_t> *ops, tree exp, bool in_p,
tree low, tree high, bool strict_overflow_p)
{
...
gsi = gsi_for_stmt (stmt);
/* In rare cases range->exp can be equal to lhs of stmt.
In that case we have to insert after the stmt rather then before
it. */
if (op == range->exp)
tem = force_gimple_operand_gsi (&gsi, tem, true, NULL_TREE, false,
GSI_CONTINUE_LINKING);
where 'stmt' is a PHI node got via SSA_NAME_DEF_STMT (op).
But "after" the PHI is at the beginning of the BB.
Probably the condition we are trying to apply some magic to leads to
a critical edge which isn't handled well here?
Sth for Jakub, not really LTO related.
