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

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

On Fri, Mar 31, 2017 at 12:40 PM, Christopher Li <sparse@chrisli.org> wrote:
> On Fri, Mar 31, 2017 at 4:55 PM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>> The very first patch of the series insure that all flags are
>> initialized to the default 'NONE'. Then the next patches build
>> on this and add info/bits to flags case by case.
>>
>> As far as I can see the patch was correct.
>
> How about a different test case. The right hand side is a const
> expression but not an int const expression.
> So the result is not an address constant.  The result should be some
> other kind of constant since both
> left hand side and right hand side are both constant expression. If
> the result has NONE then it is wrong.

OK, I think I begin to understand.
It's important that the standard is not coherent on the notion of
constant vs. constant expression.
This distinction exists for integers:
- a case in a switch statement requires an integer constant
- initializers are happy with integer constant expressions.
For address, no such distinction exists, the standard specifically
states in [6.6.9]:
    An address constant is a null pointer, a pointer to an lvalue
    designating an object of static storage duration, or a pointer
    to a function designator; it shall be created explicitly using
    the unary & operator or an integer constant cast to pointer type,
    or implicitly by the use of an expression of array or function type.
    The array-subscript [] and member-access . and -> operators,
    the address & and indirection * unary operators, and pointer casts
    may be used in the creation of an address constant, but the value
    of an object shall not be accessed by use of these operators.

If the LHS is not an address constant, the result will not be any kind
of constexprs. And if the LHS is an address constant but the RHS is
not an integer constant expression then the result will also not be any
kind of constexprs. Which leave us with the case covered here.
Am I missing something?

-- Luc