From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55560 invoked by alias); 11 May 2017 08:18:24 -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 55397 invoked by uid 89); 11 May 2017 08:18:23 -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= 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 08:18:22 +0000 Received: from ball (unknown [IPv6:2620:101:80f2:224:56ee:75ff:fe52:afb9]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id EAEAEC06C; Thu, 11 May 2017 08:18:20 +0000 (UTC) Date: Thu, 11 May 2017 08:23:00 -0000 From: Trevor Saunders To: Richard Biener Cc: tbsaunde+gcc@tbsaunde.org, GCC Patches , Richard Sandiford Subject: Re: [PATCH 05/13] allow constructing a auto_vec with a preallocation, and a possibly larger actual allocation size Message-ID: <20170511081817.phelh2tt657qfqqv@ball> References: <20170509205242.2237-1-tbsaunde+gcc@tbsaunde.org> <20170509205242.2237-6-tbsaunde+gcc@tbsaunde.org> <87shkdqk16.fsf@linaro.org> <20170511074541.rwul5dtzdpgbmx76@ball> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170306 (1.8.0) X-SW-Source: 2017-05/txt/msg00858.txt.bz2 On Thu, May 11, 2017 at 10:01:51AM +0200, Richard Biener wrote: > On Thu, May 11, 2017 at 9:45 AM, Trevor Saunders wrote: > > 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 > 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 ();