------- Comment #13 from rguenth at gcc dot gnu dot org 2007-04-21 16:37
-------
The interesting thing is that we
Created value VH.0 for (<unnamed-unsigned:4>) 31
The bug (compared to the trunk) is, that tree-ssa-pre.c:try_look_through_load
on the 4.2 branch manages to propagate the 31 while trunk does not
(surprisingly).
On 4.2 we have for the def_stmt
# SFT.0D.1539_2 = V_MUST_DEF <SFT.0D.1539_1>;
sD.1526.b6D.1525 = 31
while on the trunk
# SFT.0_10 = VDEF <SFT.0_9(D)> { SFT.0 }
s.b6 = 31
and the predicate !ZERO_SSA_OPERANDS (def_stmt, SSA_OP_VIRTUAL_USES) evaluates
differently on them. *sigh*
This causes us to have the unfolded expression created from
create_value_expr_from which we then fold incorrectly by folding
of double conversion code.
One fix is to fold the expression we generate with like
Index: tree-ssa-pre.c
===================================================================
--- tree-ssa-pre.c (revision 124018)
+++ tree-ssa-pre.c (working copy)
@@ -2973,6 +2973,9 @@ create_value_expr_from (tree expr, basic
TREE_OPERAND (vexpr, i) = val;
}
+ if (UNARY_CLASS_P (vexpr))
+ vexpr = fold (vexpr);
+
return vexpr;
}
which then results in the correct
main ()
{
short unsigned int D.1536;
short unsigned int D.1535;
int D.1534;
<unnamed-unsigned:6> D.1533;
<unnamed-unsigned:4> D.1532;
<unnamed-unsigned:4> D.1531;
<unnamed-unsigned:6> D.1530;
<bb 2>:
s.b6 = 31;
D.1530_3 = 31;
D.1531_4 = 15;
s.b4 = D.1531_4;
D.1532_7 = 15;
D.1533_8 = 15;
s.b6 = D.1533_8;
D.1535_10 = BIT_FIELD_REF <s, 16, 0>;
D.1536_11 = D.1535_10 & 1008;
D.1534_12 = D.1536_11 != 240;
return D.1534_12;
}
now another question is, why we "regressed" here on the mainline. Danny?
(I guess we might get more unfolded trees by constants propagated by
the look from load code - like an addition)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
