Re: [PATCH 05/13] allow constructing a auto_vec with a preallocation, and a possibly larger actual allocation size

[Richard Sandiford <richard.sandiford@linaro.org>]

Trevor Saunders <tbsaunde@tbsaunde.org> writes:
> On Thu, May 11, 2017 at 10:01:51AM +0200, Richard Biener wrote:
>> On Thu, May 11, 2017 at 9:45 AM, Trevor Saunders
>> <tbsaunde@tbsaunde.org> wrote:
>> > On Wed, May 10, 2017 at 07:54:13AM +0100, Richard Sandiford wrote:
>> >> tbsaunde+gcc@tbsaunde.org writes:
>> >> > From: Trevor Saunders <tbsaunde+gcc@tbsaunde.org>
>> >> >
>> >> > This allows us to set the capacity of the vector when we construct it,
>> >> > and still use a stack buffer when the size is small enough.
>> >> >
>> >> > gcc/ChangeLog:
>> >> >
>> >> > 2017-05-09  Trevor Saunders  <tbsaunde+gcc@tbsaunde.org>
>> >> >
>> >> >     * genrecog.c (int_set::int_set): Explicitly construct our
>> >> > auto_vec base class.
>> >> >     * vec.h (auto_vec::auto_vec): New constructor.
>> >> > ---
>> >> >  gcc/genrecog.c |  8 +++++---
>> >> >  gcc/vec.h      | 12 ++++++++++++
>> >> >  2 files changed, 17 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/gcc/genrecog.c b/gcc/genrecog.c
>> >> > index 6a9e610e7a0..b69043f0d02 100644
>> >> > --- a/gcc/genrecog.c
>> >> > +++ b/gcc/genrecog.c
>> >> > @@ -1407,14 +1407,16 @@ struct int_set : public auto_vec <uint64_t, 1>
>> >> >    iterator end ();
>> >> >  };
>> >> >
>> >> > -int_set::int_set () {}
>> >> > +int_set::int_set () : auto_vec<uint64_t, 1> () {}
>> >> >
>> >> > -int_set::int_set (uint64_t label)
>> >> > +int_set::int_set (uint64_t label) :
>> >> > +  auto_vec<uint64_t, 1> ()
>> >> >  {
>> >> >    safe_push (label);
>> >> >  }
>> >> >
>> >> > -int_set::int_set (const int_set &other)
>> >> > +int_set::int_set (const int_set &other) :
>> >> > +  auto_vec<uint64_t, 1> ()
>> >> >  {
>> >> >    safe_splice (other);
>> >> >  }
>> >>
>> >> Is this part of the patch necessary?  Won't the default constructor
>> >> be used anyway?
>> >
>> > Well, without the change to the copy constructor we get this bootstrap
>> > warning.
>> >
>> > /src/gcc/gcc/genrecog.c: In copy constructor ‘int_set::int_set(const int_set&)’:
>> > /src/gcc/gcc/genrecog.c:1417:1: error: base class ‘class auto_vec<long
>> > unsigned int, 1>’ should be explicitly initialized in the copy
>> > constructor [-Werror=extra]
>> >  int_set::int_set (const int_set &other)
>> >   ^~~~~~~
>> >
>> >>
>> > So we need to do something about that.  I'm not sure the other cases are
>> > necessary, but I was there, and being explicit seemed better than
>> > leaving it implicit.
>> 
>> Ah,
>> 
>>           /* If these initializations are taking place in a copy constructor,
>>              the base class should probably be explicitly initialized if there
>>              is a user-defined constructor in the base class (other than the
>>              default constructor, which will be called anyway).  */
>>           if (extra_warnings
>>               && DECL_COPY_CONSTRUCTOR_P (current_function_decl)
>>               && type_has_user_nondefault_constructor (BINFO_TYPE (subobject)))
>>             warning_at (DECL_SOURCE_LOCATION (current_function_decl),
>>                         OPT_Wextra, "base class %q#T should be explicitly "
>>                         "initialized in the copy constructor",
>>                         BINFO_TYPE (subobject));
>> 
>> ok - fine then.  Probably could be avoided with
>> 
>>  auto_vec() = defaulted;
>> 
>> (or how you'd write that)
>
> Well, we don't get to use = default in C++98, so we'd have to ifdef, I
> guess it could work since it would fix the warning outside of stage 1,
> but seems pretty gross.

Yeah.  OK for the genrecog.c bit.

Thanks,
Richard