[PATCH 05/13] allow constructing a auto_vec with a preallocation, and a possibly larger actual allocation size
Trevor Saunders
tbsaunde@tbsaunde.org
Thu May 11 08:23:00 GMT 2017
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.
Trev
>
> 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