Re: PATCH RFC: Narrowing POINTER_PLUS_EXPR can be a static initializer

[Ian Lance Taylor <iant at google dot com>]

Eric Botcazou <ebotcazou@adacore.com> writes:

>> The regression occurs because 4.2 generates a MINUS_EXPR and
>> 4.3/mainline generate a POINTER_PLUS_EXPR.  There is special code in
>> initializer_constant_valid_p to handle a narrowing subtraction.  That
>> code is currently only used for MINUS_EXPR.  The appended patch uses
>> the same code for POINTER_PLUS_EXPR as well.
>
> It seems to me that there is a slight confusion in the patch as to what is 
> meant to convey the "narrowing".  The original code was
>
>       /* Support narrowing differences.  */
>       if (INTEGRAL_TYPE_P (endtype))
>        {
>          tree op0, op1;
>
> The new code is
>
>       /* Support narrowing differences.  */
>       ret = narrowing_initializer_constant_valid_p (value, endtype);
>       if (ret != NULL_TREE)
> 	return ret;
>
> /* A subroutine of initializer_constant_valid_p.  VALUE is either a
>    MINUS_EXPR or a POINTER_PLUS_EXPR, and ENDTYPE is a narrowing
>    conversion to something smaller than a pointer.  This returns
>    null_pointer_node if the resulting value is an absolute constant
>    which can be used to initialize a static variable.  Otherwise it
>    returns NULL.  */
>
> static tree
> narrowing_initializer_constant_valid_p (tree value, tree endtype)
>
>
> AFAICS the "narrowing" is not conveyed by "endtype" but rather by the operands 
> of the operation (there is no return NULL_TREE at the end of the conditional 
> blocks).  And, in the new code, "endtype" can be anything.

You're right, an exact translation would check for INTEGRAL_TYPE_P
(endtype) in the MINUS_EXPR case.  As far as I can see it doesn't
actually matter, because the only case which is handled differently is
a subtraction of two labels, and it seems to me that that is a
constant regardless.  But, yes, the name and the comment are wrong.
I'll look into fixing it.

Ian