On Wed, Jan 10, 2018 at 9:59 PM, Jeff Law <l...@redhat.com> wrote:
> On 01/06/2018 11:58 PM, Prathamesh Kulkarni wrote:
> [ Snip ]
>
>>> I think with those changes we're probably in good shape.  But please
>>> repost for final approval.
>> I have the updated the attached version with your suggestions.
>> Does it look OK ?
>> Bootstrap+test passes on x86_64-unknown-linux-gnu.
>>
>> Thanks,
>> Prathamesh
>>> jeff
>>
>> pr82665-9.diff
>>
>>
>> diff --git a/gcc/vr-values.c b/gcc/vr-values.c
>> index 794b4635f9e..41a4a0b041f 100644
>> --- a/gcc/vr-values.c
>> +++ b/gcc/vr-values.c
>> @@ -793,6 +793,39 @@ vr_values::extract_range_from_binary_expr (value_range 
>> *vr,
>>
>>    extract_range_from_binary_expr_1 (vr, code, expr_type, &vr0, &vr1);
>>
>> +  /* Set value_range for n in following sequence:
>> +     def = __builtin_memchr (arg, 0, sz)
>> +     n = def - arg
>> +     Here the range for n can be set to [0, PTRDIFF_MAX - 1]. */
>> +
>> +  if (vr->type == VR_VARYING
>> +      && code == POINTER_DIFF_EXPR
>> +      && TREE_CODE (op0) == SSA_NAME
>> +      && TREE_CODE (op1) == SSA_NAME)
>> +    {
>> +      tree op0_ptype = TREE_TYPE (TREE_TYPE (op0));
>> +      tree op1_ptype = TREE_TYPE (TREE_TYPE (op1));
>> +      gcall *call_stmt = NULL;
>> +
>> +      if (TYPE_MODE (op0_ptype) == TYPE_MODE (char_type_node)
>> +       && TYPE_PRECISION (op0_ptype) == TYPE_PRECISION (char_type_node)
>> +       && TYPE_MODE (op1_ptype) == TYPE_MODE (char_type_node)
>> +       && TYPE_PRECISION (op1_ptype) == TYPE_PRECISION (char_type_node)
> Note that while the operands of POINTER_DIFF_EXPR can be pointers to
> different types, we do require that they have the same mode and
> precision.  So the tests of TYPE_MODE and TYPE_PRECISION for op1_ptype
> are not needed.
>
> OK with those two checks removed.
>
> Jeff
>
> ps. FWIW, the close a stage in our development cycle is a patch
> submission deadline.  So if a patch is submitted prior to the deadline,
> then it can move forward, even if review/approval happens after the
> deadline.

IMHO not.  Stage3 is exactly to be able to flush out patches like this if they
have been posted during stage1.  This isn't a critical bug fix or anything like
that and so it can wait for the next stage1.

Richard.

Reply via email to