On 21/07/15 11:11, Richard Biener wrote: > On Tue, 21 Jul 2015, Kyrill Tkachov wrote: > >> On 21/07/15 08:24, Richard Biener wrote: >>> On Mon, 20 Jul 2015, Kyrill Tkachov wrote: >>> >>>> Hi all, >>>> >>>> This patch fixes the PR in question which is a miscompilation of >>>> gcc.dg/fixed-point/unary.c on arm. >>>> It just restricts the A - B -> A + (-B) transformation when the type is >>>> fixed-point. >>>> >>>> This fixes the testcase for me. >>>> Is this the right approach? >>>> >>>> Bootstrap and test on arm and x86 running. >>>> >>>> Ok if testing is clean? >>> Ok, but I think the fold-const.c code has the same issue, no: >>> >>> /* A - B -> A + (-B) if B is easily negatable. */ >>> if (negate_expr_p (arg1) >>> && !TYPE_OVERFLOW_SANITIZED (type) >>> && ((FLOAT_TYPE_P (type) >>> /* Avoid this transformation if B is a positive REAL_CST. >>> */ >>> && (TREE_CODE (arg1) != REAL_CST >>> || REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1)))) >>> || INTEGRAL_TYPE_P (type))) >>> return fold_build2_loc (loc, PLUS_EXPR, type, >>> fold_convert_loc (loc, type, arg0), >>> fold_convert_loc (loc, type, >>> negate_expr (arg1))); >>> >>> ah, no. The above only applies to float-type and integral-types. >>> >>> Thus yes, your patch is ok. Can you double-check the other pattern, >>> >>> /* -(A + B) -> (-B) - A. */ >>> (simplify >>> (negate (plus:c @0 negate_expr_p@1)) >>> (if (!HONOR_SIGN_DEPENDENT_ROUNDING (element_mode (type)) >>> && !HONOR_SIGNED_ZEROS (element_mode (type))) >>> (minus (negate @1) @0))) >>> >>> ? >> Thanks, committed with r226028. >> I can add (FLOAT_TYPE_P (type) || INTEGRAL_TYPE_P (type)) to the condition. >> That would more closely mirror the original logic, right? >> That passes x86_64 bootstrap and aarch64 testing looks ok. > Yeah, that works for me, too. How about this patch then? Bootstrapped and tested on x86_64 and aarch64. Thanks, Kyrill 2015-07-23 Kyrylo Tkachov * match.pd (-(A + B) -> (-B) - A): Restrict to floating point and integral types. > > Thanks, > Richard. >