On Thu, Nov 07, 2013 at 04:15:11PM +0100, Marek Polacek wrote:
> Here, forward propagation turned
> _6 = a.1_5 & 1;
> _7 = (_Bool) _6;
> into
> _7 = (_Bool) a.1_5;
> but that's wrong: e.g. if a = 2 then (_Bool) _6 is 0, but (_Bool) a.1_5 is 1.
> If a is an odd number, this is correct, but we don't know the value
> of a, so I disabled this optimization for "x & 1" cases. For e.g. "x & 255",
> this still works correctly.
>
> In this PR, VRP created wrong ASSERT_EXPR because of this, thus we were
> miscompiling the following testcase...
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk?
Isn't the problem here not the constant 1, but the fact that TREE_CODE
(lhs_type) == BOOLEAN_TYPE, with the special properties of boolean types?
I mean, if lhs_type is say some normal INTEGER_TYPE with precision 1
(or say 3 and stmt & 3 etc.), then the cast alone should cover the required
masking.
> 2013-11-07 Marek Polacek <pola...@redhat.com>
>
> PR tree-optimization/59014
> * tree-ssa-forwprop.c (simplify_conversion_from_bitmask): Don't
> optimize x & 1 expressions here.
> testsuite/
> * gcc.dg/torture/pr59014.c: New test.
>
> --- gcc/tree-ssa-forwprop.c.mp 2013-11-07 14:30:43.785733810 +0100
> +++ gcc/tree-ssa-forwprop.c 2013-11-07 14:42:31.836765375 +0100
> @@ -1199,9 +1199,16 @@ simplify_conversion_from_bitmask (gimple
> if (TREE_CODE (rhs_def_operand1) == SSA_NAME
> && ! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs_def_operand1)
> && TREE_CODE (rhs_def_operand2) == INTEGER_CST
> + /* We can't turn
> + _6 = a & 1;
> + _7 = (_Bool) _6;
> + into
> + _7 = (_Bool) a;
> + as that's wrong if A is an even number. */
> + && ! integer_onep (rhs_def_operand2)
> && operand_equal_p (rhs_def_operand2,
> build_low_bits_mask (TREE_TYPE (rhs_def_operand2),
> - TYPE_PRECISION (lhs_type)),
> + TYPE_PRECISION (lhs_type)),
> 0))
> {
> /* This is an optimizable case. Replace the source operand
>
> Marek
Jakub
