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

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

On Wed, Nov 23, 2016 at 11:12:02AM +0800, Christopher Li wrote:
> +static int a[] = {
> +       [(int)0] = 0,           // OK
> +       [(int)(int)0] = 0,      // OK
> +       [(int)0.] = 0,          // OK
> +       [(int)(int)0.] = 0,     // OK
> +       [(int)__builtin_choose_expr(0, 0, 0)] = 0,      // OK
> +       [(int)__builtin_choose_expr(0, 0, 0.)] = 0,     // OK
> +
> +       [(int)(float)0] = 0,    // KO
> 
> Why is this one KO? It seems perfectly fine to force a floating
> type into a integer constant expression.
> 
> per [6.6.6]  quote: on integer constant expression:
>  " and floating constants that are the
> immediate operands of casts. Cast operators in an integer constant
> expression shall only
> convert arithmetic types to integer types,"

But, quoting the beginning of 6.6/6:
    An integer constant expression shall have integer type and shall
    only have operands that are integer constants, enumeration constants,
    character constants, sizeof expressions whose results are integer
    constants, and **floating constants** that are the immediate operands
    of casts.

and the part '(float) 0' is none of these.

> +       [(int)(float)0.] = 0,   // KO
> +
> +       [(int)(void*)0] = 0,    // KO
> Also this one should be fine?

same for '(void *) 0'.

It's obvious for me and you that those once casted to (int) should
evaluate to '0' and thus are constant expression but the strict
interpretation of the standard say something else.

And to be honest, I find ridiculous that '(int) 0.0' is a integer
constant expression and '(int)(float)0' is not.

IIRC, Nicolai had foreseen to relax those if needed, possibly even
in one of the later patch or to introduce a '-Wstrict' option or
something like this.


Luc