https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 3 Jun 2016, shiva0217 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 > > --- Comment #14 from Shiva Chen <shiva0217 at gmail dot com> --- > I'm not sure my understanding was correct. > > To my understanding, TYPE_OVERFLOW_UNDEFINED is true imply that signed > overflow > won't occur. > > E.g. > > in tree-scalar-evolution.c > > simple_iv (...) > { > ... > iv->no_overflow = (!folded_casts && ANY_INTEGRAL_TYPE_P (type) > && TYPE_OVERFLOW_UNDEFINED (type)); > } > > At the beginning, I thought we could use TYPE_OVERFLOW_UNDEFINED to guard the > transformation from (short)abs((int)short_var) to abs (short_var). > > The transformation should be safe if overflow won't occur. But only overflow in type int is guaranteed to not occur. > From Richard's comment 13 > > If we defined a new gimple ABSU_EXPR (x), then undefined behavior gimple IR > could be avoided and the transformation could always been done. > > ABS_EXPR (x) -> (typeof x) ABSU_EXPR (x) > > ABS_EXPR (INT_MIN) -> (INT) ABSU_EXPR (INT_MIN) -> (INT) (-INT_MIN) -> INT_MIN > > According to the comment from Joseph > https://gcc.gnu.org/ml/gcc/2013-06/msg00247.html > RTL abs are modulo. Everything in RTL is modulo. > Could we expand the semantic of ABS_EXPR > which allow ABS_EXPR (INT_MIN) -> INT_MIN directly ? > > Then the semantic of ABS_EXPR could be the same as RTL abs. We could, but then this would effectively say that for ABS_EXPR TYPE_OVERFLOW_WRAPS always holds. > And I saw the comment in fold-const.c > > bool > tree_unary_nonnegative_warnv_p (enum tree_code code, tree type, tree op0, > bool *strict_overflow_p) > { > if (TYPE_UNSIGNED (type)) > return true; > > switch (code) > { > case ABS_EXPR: > /* We can't return 1 if flag_wrapv is set because > ABS_EXPR<INT_MIN> = INT_MIN. */ > if (!INTEGRAL_TYPE_P (type)) > return true; > if (TYPE_OVERFLOW_UNDEFINED (type)) > { > *strict_overflow_p = true; > return true; > } > > Dose it mean ABS_EXPR already support the semantic ABS_EXPR (INT_MIN) -> > INT_MIN ? Yes, of course - only if !TYPE_OVERFLOW_UNDEFINED the situation that ABS_EXPR (x) < 0 can validly occur (for x equal to the minimum value of its type). > Please correct me, if I misunderstanding something. > >
