Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression

[Jason Merrill <jason@redhat.com>]

On 03/30/2016 12:32 PM, Martin Sebor wrote:
> On 03/30/2016 09:30 AM, Jason Merrill wrote:
>> On 03/29/2016 11:57 PM, Martin Sebor wrote:
>>>> Are we confident that arr[0] won't make it here as POINTER_PLUS_EXPR or
>>>> some such?
>>>
>>> I'm as confident as I can be given that this is my first time
>>> working in this area.  Which piece of code or what assumption
>>> in particular are you concerned about?
>>
>> I want to be sure that we don't fold these conditions to false.
>>
>> constexpr int *ip = 0;
>> constexpr struct A { int ar[3]; } *ap = 0;
>>
>> static_assert(&ip[0] == 0);
>> static_assert(&(ap->ar[0]) == 0);
>
> I see.  Thanks for clarifying.  The asserts pass.  The expressions
> are folded earlier on (in fact, as we discussed, the second one
> too early and is accepted even though it's undefined and should be
> rejected in a constexpr context) and never reach fold_comparison.

Good, then let's add at least the first to one of the tests.

> +	       /* Avoid folding references to struct members at offset 0 to
> +		  prevent tests like '&ptr->firstmember == 0' from getting
> +		  eliminated.  When ptr is null, although the -> expression
> +		  is strictly speaking invalid, GCC retains it as a matter
> +		  of QoI.  See PR c/44555. */
> +	       && (TREE_CODE (op0) != ADDR_EXPR
> +		   || TREE_CODE (TREE_OPERAND (op0, 0)) != COMPONENT_REF
> +		   || compare_tree_int (DECL_FIELD_OFFSET ((TREE_OPERAND
> +				           (TREE_OPERAND (op0, 0), 1))), 0))

Can we look at offset/bitpos here rather than examine the tree structure 
of op0?  get_inner_reference already examined it for us.

Also, it looks like you aren't handling the case with the operands 
switched, i.e. 0 == p and such.

Jason