From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by sourceware.org (Postfix) with ESMTPS id 873B6385BF83 for ; Tue, 7 Apr 2020 09:29:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 873B6385BF83 Received: by mail-lf1-x144.google.com with SMTP id f8so1780066lfe.12 for ; Tue, 07 Apr 2020 02:29:55 -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=n65L/fcEZ0PgYpa5JInMDOilb7Qh7Q8pwcxqm7+pagM=; b=DeHIZcheDzJqutDBFqIt0g2vc7VLH3C0YuGOIiOe2Y26tPPNuHMRnZmC3Uj6ZLhs64 /y/6b+1+homH2Pt00fLUywfGTbjsv6n5pQVwzeWBkGLsVJ/3HwIPhBMOqgC+ZAzW8/L0 nLsOJTOun7E6RdzV78LxzqetgQtHW54JCgW8GF3mabfDObATrJHYXuRpjjfwZbCOzhCp +em5OalG3Usgox2okTjEG4s4m9lHMVpOA3Xlem7gMWCj57JuvepdMbBQnIrjL/kqknmM AHPD7rWPCHuSh1TUaNZUUmHHVXfY9v2ThzrLc6vV9aGDpnHLWY59ccCA2Q3JuDzGOhSj aQnA== X-Gm-Message-State: AGi0Pub7v6K+dZ425vjRhDpScw1CW9XYzLCC0uc7P1wO7w2GG4WQx/wu KF9wCyj2GPqvUnXSj1TOdLRMNWYAqGX+rulbEog= X-Google-Smtp-Source: APiQypLxwcU5XZFra7DV+kU5KVX6+Mswn7uZ1Ubkf+ZtuNR3jCgfqgxPpr9GTAsFAfNhUoHYvAksUFFiQWBvWfGwXgI= X-Received: by 2002:ac2:5c07:: with SMTP id r7mr988578lfp.160.1586251794201; Tue, 07 Apr 2020 02:29:54 -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: Richard Biener Date: Tue, 7 Apr 2020 11:29:42 +0200 Message-ID: Subject: Re: [PATCH] Check DECL_CONTEXT of new/delete operators. To: Jonathan Wakely 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=-4.3 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 09:29:57 -0000 On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely wro= te: > > 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 the > > 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 storage > > is instead provided by the implementation or provided by extending the > > allocation of another new-expression.' > > At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94295#c6 Richard Smith > 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 at = 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 have 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. That would further suggest that we need to mark the allocation/deallocation points somehow and _not_ base the optimization on the called new/delete "function" (maybe with an exception of the global ::new and ::delete). Richard.