[PATCH, vtv update] Change fixed size array to a vector; fix diagnostic messages.

Caroline Tice cmtice@google.com
Wed Aug 28 17:41:00 GMT 2013


On Wed, Aug 28, 2013 at 10:30 AM, Diego Novillo <dnovillo@google.com> wrote:
> On 2013-08-28 12:59 , Caroline Tice wrote:
>
>>  static void
>> -output_set_info (tree record_type, tree *vtbl_ptr_array, int array_size)
>> +output_set_info (tree record_type, vec<tree> *vtbl_ptr_array)
>
>

Okay, will do.

> Since this function does not modify vtbl_ptr_array, you could pass it by
> value.
>
>>
>> @@ -1023,23 +1010,23 @@ register_all_pairs (tree body)
>>
>>        if (flag_vtv_debug)
>>          output_set_info (current->class_info->class_type,
>> -                         vtbl_ptr_array, num_vtable_args);
>> +                         vtbl_ptr_array);
>>
>> -      if (num_vtable_args > 1)
>> +      if (vtbl_ptr_array->length() > 1)
>>          {
>> -          insert_call_to_register_set (current->class_name,
>> num_vtable_args,
>> +          insert_call_to_register_set (current->class_name,
>>                                         vtbl_ptr_array, body, arg1, arg2,
>>                                         size_hint_arg);
>>            registered_at_least_one = true;
>>          }
>> -      else if (num_vtable_args >= 0)
>> +      else
>

num_vtable_args  was an int that we manually incremented/decremented,
so it might have been negative.  I am
assuming that a vec<tree>.length() can never be negative. So before
the else-clause was explicitly checking that the value was 0 or 1
(since the if-condition takes all values greater than 1.  Now I am
implicitly assuming that when we get to the else-clause the value must
be 0 or 1, because the if-condition took care of all values greater
than 1, and values less that zero cannot occur.  Is that assumption
incorrect?

Do you need to review this again after I fix your suggestion, or can I
go ahead and commit it after?

-- Caroline
cmtice@google.com

>
> You've changed the meaning of this else now.  Intended?  I can't tell from
> context.
>
> The patch looks fine, otherwise.
>
>
> Diego.



More information about the Gcc-patches mailing list