On 03/29/2016 12:54 PM, Jason Merrill wrote:
> On 03/28/2016 06:04 PM, Martin Sebor wrote:
>> +           && compare_tree_int (arg1, 0) == 0)
>
> This can be integer_zerop.

Sure.

>
>> +        case GE_EXPR:
>> +        case EQ_EXPR:
>> +        case LE_EXPR:
>> +          return boolean_false_node;
>> +        case GT_EXPR:
>> +        case LT_EXPR:
>> +        case NE_EXPR:
>> +          return boolean_true_node;
>
> EQ and NE make sense, but I would expect both > and >= to be true, < and
> <= to be false.

I was convinced I had a reason for this but it doesn't seem
to affect regression test results so I must have been wrong.

Relational expressions involving object and null pointers are
undefined in C and I thought unspecified in C++, but given that
GCC evaluates (0 < p) to true it looks like you're right and C++
does seem to require all the others to evaluate as you said.

With the decision to remove the nullptr changes I tried to keep
the amount of testing of null pointers to the minimum necessary
to exercise the fix for comment #10 on 67376.  In light of your
expectation I've added a test to better exercise the relational
expressions involving pointers to struct data members.
Interestingly, stepping through it revealed that the problem
cases you pointed out above are actually handled by
generic_simplify() and never end up in fold_comparison().

Attached is an updated patch.

> 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?

Martin