Re: [PATCH v3 00/21] improve constexpr handling

[Nicolai Stange <nicstange@gmail.com>]

Christopher Li <sparse@chrisli.org> writes:

> On Thu, Nov 24, 2016 at 12:43 AM, Nicolai Stange <nicstange@gmail.com> wrote:
>>
>> I don't think that this would qualify as a constant expression of any
>> type.
>>
>>> How about (void*)(0 + 'a') and (void*)0 + 'a', are they address constant
>>> or not?
>>
>> Strictly speaking, neither of them is.
>>
>> Despite of this, we would (hopefully) mark the second case as an address
>> constant though.
>>
>> Reason: this series flags address constants as such because they may be
>> used as a "constant expression in an initializer", i.e. as initializers
>> for static storage duration variables.
>
> That is good info. Thanks for the clarify.
>
> BTW, gcc does not seem to complain about const integer issue on,
>          [(int)(float)0] = 0,    // KO
>          [(int)(void*)0] = 0,    // KO
> gcc seems does what make snese rather than stick to the book.

To give you some background: when I started this, my initial intent was
to move the constness inspection from the expression building stage in
expression.c to their evaluation in evaluation.c. This would be needed
in order to decide whether the outcome of __builtin_choose_expr() is a
constant expression, for example.

While doing this, I recognized that sparse's current constant expression
tagging scheme was quite limited and I had to touch everything related
to it anyway. So I asked on this list on whether it would be a good
thing to let sparse be more strict than gcc in this regard and the
feedback was that it certainly would (at user option).


> In your patch:

Can you tell which one? If not, would resending this series help?

> static struct token *builtin_types_compatible_p_expr(struct token *token,
>                                                      struct expression **tree)
>  {
>         struct expression *expr = alloc_expression(
>                 token->pos, EXPR_COMPARE);
> -       expr->flags = Int_const_expr;
>         expr->op = SPECIAL_EQUAL;
>         token = token->next;
>         if (!match_op(token, '('))
>
> I think __builtin_xxx function expand similar to the processor
> macro. In that sense, we might want to the consider this expression
> as integer constant express as if the __builtin_xxx call is either 0 or 1.
>
> Again, gcc does not complain about:
>        [__builtin_types_compatible_p(typeof(1), int)] = 0,   // KO
>
> This makes sense, but not according the "strict" rules.

After [21/21] ("evaluation: treat comparsions between types as integer
constexpr"), sparse should treat __builtin_types_compatible_p() as an
integer constant expression, just as gcc does.

After all, the standard doesn't say anything about
__builtin_types_compatible_p()...

So, if the above testcase really fails after this series, it's either a
bug or an artifact of having this typeof() in there (or both), I
think.


>>>
>>> Basically, there are six bits as basic element. One bit per element.
>>> Integer constant, enum constant, char constant, float constant,
>>> address constant,
>>> arithmetic constant.
>>
>> + integer constant *expression*
>>
>> Take 0 + 0, for example: this is not an integer constant, but an integer
>> constant *expression* (and an arithmetic constant expression as well).
>
> Ah, I see. I change my plan according this. The six basic element define as:
> Integer constant, enum constant, char constant, float constant,
> address constant, composite op.
>
> The composite op bit get set after binary operation or uniop.
> The flags can have more than one bit set for the expression.
>
> Integer constant expression can be tested as:
>
> !(flags & ( Addr | Float) ) && flag
>
> Arithmetic constant expression can be tested as:
>
> !(flags & Addr) ) && flag
>
> Do you see any problem with this internal representation?

(int)0.0 is an integer constant expression.

In your scheme, it would have "composite op" and "float" set?
The integer constant expression test you proposed above would
fail in this case.


Thanks,

Nicolai