Re: [PATCH v2 03/13] expression: examine constness of binops and alike at evaluation only

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

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