From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49551 invoked by alias); 11 May 2017 08:47:11 -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 48913 invoked by uid 89); 11 May 2017 08:47:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f177.google.com Received: from mail-wr0-f177.google.com (HELO mail-wr0-f177.google.com) (209.85.128.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 May 2017 08:47:08 +0000 Received: by mail-wr0-f177.google.com with SMTP id l50so14562938wrc.3 for ; Thu, 11 May 2017 01:47:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=sGTKNQB2g6F9fvR4iqBkV8j1zGtxxyQ2/ClmSnnZ2CI=; b=Fqss1AgH9yi3MShrwRuCfOTmlsMcggbt9WunwZgbHJYB1hmW7Y4EV6eOy8o7+mxfM8 sHleZ4gT1ZYIxPjKCRCWMYjJ0rvkIpZHSoEggiRhrfunZV+SCpP0U8sStlACwOFwb5oZ 1gDui2Ez+bubVkpfSS3rX4Vx+dxunTL7qqm4UjbSi+W5P2DyZz1+cAOtCDQB6OMfS4IF iyBjodDaKzN+ml3OTtcvK6EGqto/eySZ972mL/9/V6yuiw7OMZVrp+13lCO6laiv1ZQ+ jm6rtuRgu9e6luD98AN07QJNEGvLfBUGAKA69xX5+ut6MB+RCfiVtX5EE0cpayJUhqxI LnaA== X-Gm-Message-State: AODbwcAfekmhTlX1bjhClUF8x83c4XOe40PN3DqFO70g/Zj0/X6w85El UnRg/e/Nl6+1JYhI X-Received: by 10.223.134.97 with SMTP id 30mr6961145wrw.161.1494492429545; Thu, 11 May 2017 01:47:09 -0700 (PDT) Received: from localhost (94.197.120.30.threembb.co.uk. [94.197.120.30]) by smtp.gmail.com with ESMTPSA id q16sm716173wmg.2.2017.05.11.01.47.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 May 2017 01:47:08 -0700 (PDT) From: Richard Sandiford To: Trevor Saunders Mail-Followup-To: Trevor Saunders ,Richard Biener , tbsaunde+gcc@tbsaunde.org, GCC Patches , richard.sandiford@linaro.org Cc: Richard Biener , tbsaunde+gcc@tbsaunde.org, GCC Patches Subject: Re: [PATCH 05/13] allow constructing a auto_vec with a preallocation, and a possibly larger actual allocation size References: <20170509205242.2237-1-tbsaunde+gcc@tbsaunde.org> <20170509205242.2237-6-tbsaunde+gcc@tbsaunde.org> <87shkdqk16.fsf@linaro.org> <20170511074541.rwul5dtzdpgbmx76@ball> <20170511081817.phelh2tt657qfqqv@ball> Date: Thu, 11 May 2017 09:04:00 -0000 In-Reply-To: <20170511081817.phelh2tt657qfqqv@ball> (Trevor Saunders's message of "Thu, 11 May 2017 04:18:17 -0400") Message-ID: <87o9uzrd9x.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-05/txt/msg00860.txt.bz2 Trevor Saunders 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 >> 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 =E2=80=98int_set::int_set= (const int_set&)=E2=80=99: >> > /src/gcc/gcc/genrecog.c:1417:1: error: base class =E2=80=98class auto_= vec> > unsigned int, 1>=E2=80=99 should be explicitly initialized in the copy >> > constructor [-Werror=3Dextra] >> > int_set::int_set (const int_set &other) >> > ^~~~~~~ >> > >> >> >> > So we need to do something about that. I'm not sure the other cases a= re >> > necessary, but I was there, and being explicit seemed better than >> > leaving it implicit. >>=20 >> Ah, >>=20 >> /* If these initializations are taking place in a copy constru= ctor, >> 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 (subob= ject))) >> warning_at (DECL_SOURCE_LOCATION (current_function_decl), >> OPT_Wextra, "base class %q#T should be explicitl= y " >> "initialized in the copy constructor", >> BINFO_TYPE (subobject)); >>=20 >> ok - fine then. Probably could be avoided with >>=20 >> auto_vec() =3D defaulted; >>=20 >> (or how you'd write that) > > Well, we don't get to use =3D 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