From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by sourceware.org (Postfix) with ESMTPS id F1F28385BF83 for ; Tue, 7 Apr 2020 11:41:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F1F28385BF83 Received: by mail-io1-xd42.google.com with SMTP id y17so2950392iow.9 for ; Tue, 07 Apr 2020 04:41:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YBYaTpRs25sPTLTL9IjUeeuMNLcDODXT4qS4jOaIIxw=; b=TYundzJeJEwNhBenJc7l9TOk30dZSUwB/RZoV9/Ijil3PBY5n+mG2MVZR4ZB7f2trT daVXc3uhxxqcPAgCe50wHoty0szacU2FwGO7d3hCSPJznugGlgfH2H/LEX0+j1xLbOAP FinisOc2dYqFsF+JxggTwOMhvRpBBYcw7+R26Vb3hM/2jSqraqvwni5cOIR4p5NvZoGS kqW0b8q7kC87gnXob2eDxeUnwmOUWc/mSDGQvv3M5LSouT5ipsYZpOVD9JOIGmXVe5iF j6lfScOJZJlv34K99tt6lQxgXZZvt5hnTKDisrKIogDQcvIIhg7rGWWDuQGqUuOO3FF4 ehYg== X-Gm-Message-State: AGi0PuY4WZMImt3ylefGeF9pNb3ZRwIFWH1S9El46Mhj5RyEFIhOYbki lJwIA8IHT8640vUTlem9KmEKko7TOnYTVLhY7EY= X-Google-Smtp-Source: APiQypLzG43YBUCYeG4+yGs6inDnc2PhSLQWpNR9g8ETJb0z2r7k6XPCrtVrv1urfi0pcyDMAstg8hnGlPQ7NItQXu8= X-Received: by 2002:a02:c551:: with SMTP id g17mr1576827jaj.52.1586259711347; Tue, 07 Apr 2020 04:41:51 -0700 (PDT) MIME-Version: 1.0 References: <20200331122907.GB62067@kam.mff.cuni.cz> <65230a52-c025-a6e3-0d31-409d37e9b2c9@suse.cz> <20200403152609.GA35629@kam.mff.cuni.cz> <0dbc191e-66f7-9878-956d-96149f20f5bf@suse.cz> In-Reply-To: From: Jonathan Wakely Date: Tue, 7 Apr 2020 11:41:39 +0000 Message-ID: Subject: Re: [PATCH] Check DECL_CONTEXT of new/delete operators. To: Richard Biener Cc: Nathan Sidwell , =?UTF-8?Q?Martin_Li=C5=A1ka?= , Jan Hubicka , GCC Patches , Marc Glisse , Jason Merrill Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 11:41:53 -0000 On Tue, 7 Apr 2020 at 10:29, Richard Biener wr= ote: > > On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely w= rote: > > > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote: > > > > > > On 4/6/20 4:34 AM, Martin Li=C5=A1ka wrote: > > > > > > > > > > > May I please ping Jason, Nathan and Jonathan who can help us here? > > > > > > On IRC Martin clarified the question as essentially 'how do you pair = up > > > operator new and operator delete calls?' (so you may delete them if t= he > > > object is not used). > > > > > > I am not sure you're permitted to remove those calls in general. All= I > > > can find is [expr.new]/12 > > > 'An implementation is allowed to omit a call to a replaceable global > > > allocation function (17.6.2.1, 17.6.2.2). When it does so, the storag= e > > > is instead provided by the implementation or provided by extending th= e > > > allocation of another new-expression.' > > > > At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94295#c6 Richard Smit= h > > summarised the rules as "new-expressions, like std::allocator, may > > obtain storage by calling 'operator new', but it's unspecified how > > often it's called and with what arguments." > > > > So if our optimisation is removing the calls to base::operator new and > > base::operator delete, but not the B::operator new call, then it seems > > to be working at the wrong level. It should be eliding any calls to > > operator new and operator delete at the point of the new-expression > > and delete-expression, not leaving one call to operator new present > > and then removing another one (which leaves the call "partially > > removed"). > > Well, the question is how to identify "operator new and operator delete a= t the > point of the new-expression and delete-expression". Currently we're > just matching up "is this a new/delete operator" and the dataflow of the > pointer. In the PR it was suggested the actual called methods should hav= e > the same DECL_CONTEXT. Honza suggested the context should have the > "same" ODR type (or be global). > > You make it sound it's much harder and the parser needs to build the > relation? You also suggest the "validness" is only OK in the context > of std::allocator and based on the unspecifiedness of the number of > allocations from the standard library. I don't think Richard's summary or my paraphrasing intends to say it only applies to std::allocator.