From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46165 invoked by alias); 11 May 2017 07:45:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 45556 invoked by uid 89); 11 May 2017 07:45:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=our X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 May 2017 07:45:45 +0000 Received: from ball (unknown [IPv6:2620:101:80f2:224:56ee:75ff:fe52:afb9]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id B909BC06A; Thu, 11 May 2017 07:45:44 +0000 (UTC) Date: Thu, 11 May 2017 07:50:00 -0000 From: Trevor Saunders To: tbsaunde+gcc@tbsaunde.org, gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Subject: Re: [PATCH 05/13] allow constructing a auto_vec with a preallocation, and a possibly larger actual allocation size Message-ID: <20170511074541.rwul5dtzdpgbmx76@ball> References: <20170509205242.2237-1-tbsaunde+gcc@tbsaunde.org> <20170509205242.2237-6-tbsaunde+gcc@tbsaunde.org> <87shkdqk16.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87shkdqk16.fsf@linaro.org> User-Agent: NeoMutt/20170306 (1.8.0) X-SW-Source: 2017-05/txt/msg00854.txt.bz2 On Wed, May 10, 2017 at 07:54:13AM +0100, Richard Sandiford wrote: > tbsaunde+gcc@tbsaunde.org writes: > > From: Trevor Saunders > > > > 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 > > > > * 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 > > iterator end (); > > }; > > > > -int_set::int_set () {} > > +int_set::int_set () : auto_vec () {} > > > > -int_set::int_set (uint64_t label) > > +int_set::int_set (uint64_t label) : > > + auto_vec () > > { > > safe_push (label); > > } > > > > -int_set::int_set (const int_set &other) > > +int_set::int_set (const int_set &other) : > > + auto_vec () > > { > > 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’ 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. 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 ();