https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61184
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Keywords| |wrong-code
Last reconfirmed| |2014-05-14
Component|lto |c
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Summary|wrong code (that hangs) by |[4.10 Regression] wrong
|LTO on x86_64-linux-gnu |code (that hangs) by LTO on
| |x86_64-linux-gnu
Target Milestone|--- |4.10.0
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. VRP2 transforms this wrongly. Can be reproduced without LTO
and just with -Os -fno-strict-overflow.
It boils down to gimplification optimizing the auto-inc in short as if
overflow would wrap. But -fno-strict-overflow does _not_ say overflow
wraps. It just says we don't treat as many things as overflowing
(yeah, quite useless).
Thus we may not do:
case PREINCREMENT_EXPR:
case PREDECREMENT_EXPR:
case POSTINCREMENT_EXPR:
case POSTDECREMENT_EXPR:
{
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
{
if (TYPE_OVERFLOW_UNDEFINED (type)
|| ((flag_sanitize & SANITIZE_SI_OVERFLOW)
&& !TYPE_OVERFLOW_WRAPS (type)))
type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
}
break;
}
but have to use !TYPE_OVERFLOW_WRAPS (type) - sanitization should have
shown this.
So it's not really a 4.10 regression only, but latent (and thus not really a
regression).
