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


Reply via email to