On 08/18/2016 08:09 PM, Kugan Vivekanandarajah wrote:
The testcase pr33738.C for warning fails with early-vrp patch. The
reason is, with early-vrp ccp2 is folding the comparison that used to
be folded in simplify_stmt_for_jump_threading. Since early-vrp does
not perform jump-threading is not optimized there.
Attached patch adds this warning to tree-ssa-ccp.c. We might also run
into some other similar issues in the future.
Bootstrapped and regression tested on x86_64-linux-gnu with no new regressions.
Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2016-08-18 Kugan Vivekanandarajah <kug...@linaro.org>
* tree-ssa-ccp.c (ccp_fold_stmt): If the comparison is being folded
and the operand on the LHS is being compared against a constant
value that is outside of type limit, issue warning.
So just to be clear, early VRP simplifies thing in a way that allows CCP
(rather than a later VRP) to do the propagation exposing the comparison
against an out-of-range constant. Right?
@@ -2147,7 +2149,11 @@ ccp_fold_stmt (gimple_stmt_iterator *gsi)
case GIMPLE_COND:
{
gcond *cond_stmt = as_a <gcond *> (stmt);
+ tree lhs = gimple_cond_lhs (stmt);
+ tree rhs = gimple_cond_rhs (stmt);
ccp_prop_value_t val;
+ wide_int min, max, rhs_val;
+ bool warn_limit = false;
/* Statement evaluation will handle type mismatches in constants
more gracefully than the final propagation. This allows us to
fold more conditionals here. */
@@ -2165,6 +2171,41 @@ ccp_fold_stmt (gimple_stmt_iterator *gsi)
fprintf (dump_file, "\n");
}
+ /* If the comparison is being folded and the operand on the LHS
+ is being compared against a constant value that is outside of
+ the natural range of LHSs type, then the predicate will
+ always fold regardless of the value of LHS. If -Wtype-limits
+ was specified, emit a warning. */
+ if (warn_type_limits
+ && INTEGRAL_TYPE_P (TREE_TYPE (lhs))
+ && (rhs = get_constant_value (rhs))
+ && (TREE-code (rhs) == INTEGER_CST))
^^^^^^^^^
I'm not sure how this could have bootstrapped & regression tested?!?
I'm OK with the general direction here, but I think you need to retest ;-)
Presumably by the type we get to this test the expression is in canonial
form? I'm thinking specifically about a case that may have started off
looking like
if (x >= y)
Where we're able to find a constant for x and that constant is out of
the range of what y can hold.
jeff