https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86479
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2018-07-11
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |9.0
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We are gimplifying via get_rename_from_scev
(uf.1_3 < 0 ? prephitmp_15 / 0 : 0 / 0) * prephitmp_40
which is gimplified to control-flow because of the side-effects happening.
We analyze _11 in a region covering the following BB (which itself isn't
in a loop we analyze but inbetween two loops):
<bb 15> :
_4 = uf.1_3 < 0;
_5 = (long int) _4;
_6 = _5 * prephitmp_15;
_9 = _6 / 0;
ws = _9;
_11 = _9 * prephitmp_40;
*aw_23(D) = _11;
and SCEV simply picks up the expressions and
fold_binary_op_with_conditional_arg
moves the division by zero into the COND_EXPR built for (long int) (uf.1_3 < 0)
* prephitmp_15. That this turns out to be profitable is because 0 / 0 is
TREE_CONSTANT and fold_binary_op_with_conditional_arg checks
/* Check that we have simplified at least one of the branches. */
if (!TREE_CONSTANT (arg) && !TREE_CONSTANT (lhs) && !TREE_CONSTANT (rhs))
return NULL_TREE;
ISTR that 0 / 0 being TREE_CONSTANT popped up lately elsewhere.
