On Wed, Aug 28, 2013 at 10:30 AM, Diego Novillo <dnovi...@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 cmt...@google.com > > You've changed the meaning of this else now. Intended? I can't tell from > context. > > The patch looks fine, otherwise. > > > Diego.