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

Richard Biener richard.guenther@gmail.com
Thu May 11 08:18:00 GMT 2017


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)

Thanks,
Richard.

> Thanks
>
> Trev
>
>> Thanks,
>> Richard
>>
>> > diff --git a/gcc/vec.h b/gcc/vec.h
>> > index fee46164b01..914f89c350c 100644
>> > --- a/gcc/vec.h
>> > +++ b/gcc/vec.h
>> > @@ -1272,6 +1272,18 @@ public:
>> >      this->m_vec = &m_auto;
>> >    }
>> >
>> > +  auto_vec (size_t s)
>> > +  {
>> > +    if (s > N)
>> > +      {
>> > +   this->create (s);
>> > +   return;
>> > +      }
>> > +
>> > +    m_auto.embedded_init (MAX (N, 2), 0, 1);
>> > +    this->m_vec = &m_auto;
>> > +  }
>> > +
>> >    ~auto_vec ()
>> >    {
>> >      this->release ();



More information about the Gcc-patches mailing list