On Mon, Jan 25, 2016 at 03:52:14PM +0100, Nicolai Stange wrote:
> Currently, the propagation of expressions' constness flags through
> binary operations, compare and logical expressions is done in two
> steps:
> - Several flags are speculatively set at expression parsing time
> - and possibly cleared again at evaluation time.
>
> Set aside this unfortunate split of code, the early propagation of
> constness flags is not able to recognize constant expressions such as
> 0 + __builtin_choose_expr(0, 0, 0)
> 0 < __builtin_choose_expr(0, 0, 0)
> 0 && __builtin_choose_expr(0, 0, 0)
> since the final expression to be thrown into the binop-like expression
> is known only after evaluation.
>
> Move the whole calculation of binary operations', compare and logical
> expressions' constness flags to the evaluation phase.
>
> Introduce support for tracking arithmetic constness propagation through
> binop-like expressions.
Same as previous patch regarding the description and splitness of the patch.
> @@ -893,14 +891,11 @@ static struct symbol *evaluate_binop(struct expression *expr)
> int rclass = classify_type(expr->right->ctype, &rtype);
> int op = expr->op;
>
> - if (expr->flags) {
> - if (!(expr->left->flags & expr->right->flags &
> - EXPR_FLAG_INT_CONST_EXPR))
> - expr->flags = EXPR_FLAG_NONE;
> - }
> -
> /* number op number */
> if (lclass & rclass & TYPE_NUM) {
> + expr->flags = expr->left->flags & expr->right->flags;
> + expr_flags_decay_consts(&expr->flags);
> +
What about expr->flags now if not TYPE_NUM?
Are we sure it's always initialized to NONE by the alloctor?
> diff --git a/validation/constexpr-binop.c b/validation/constexpr-binop.c
> @@ -0,0 +1,33 @@
> +static int a[] = {
> + [0 + 0] = 0, // OK
> + [0 + 0.] = 0, // KO
> + [(void*)0 + 0] = 0, // KO
> + [0 + __builtin_choose_expr(0, 0, 0)] = 0, // OK
> + [0 + __builtin_choose_expr(0, 0., 0)] = 0, // OK
> + [0 + __builtin_choose_expr(0, 0, 0.)] = 0, // KO
> + [0 < 0] = 0, // OK
> + [0 < 0.] = 0, // KO
It's not clear to me what the standrad says about this case.
What about the constness of 'usual artihmetic conversions' ?
Also GCC don't complain on this one.
> + [0 && 0.] = 0, // KO
Same here.
Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
