From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by sourceware.org (Postfix) with ESMTPS id CFFA5385B831 for ; Mon, 6 Apr 2020 12:45:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CFFA5385B831 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nathanmsidwell@gmail.com Received: by mail-qv1-xf43.google.com with SMTP id p19so7408829qve.0 for ; Mon, 06 Apr 2020 05:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YMyBCC1er2v7AUySiV6hMeDsPgqGNaiY8szIxmAYK48=; b=jKs7vsR+CaDDvjrUBaeuxHHkf8x6oHx5NVLWyd53oH6Fwx+evfG/8h9HbkTHkoNI8I w10jrRWCJaBZxQJ9WdxlVpiKleMQORJ3gZJUEmpO9GsjjitNuzMCpnfH0l0ZlNEo0cwO AtK3r39IM3ffTXQy/Qp2oO5rXZPbJ1X/+nMr0DTSbg3y/is2cA18aYz9rnBOri7bHD44 gXVuh14/1/dJOOH3MGRXsYDVY0AswGQbbuc7xdth2NeBjsK7L55t+V8H5F64JxPZHMAR 3O74xCyqLcRVwyPRG2046StHA7/uHS1ggmObCoV0klZw7XKjt0W6H+Co71bcvJqmhmun D4Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YMyBCC1er2v7AUySiV6hMeDsPgqGNaiY8szIxmAYK48=; b=Io8WNqvQEJy5Gu1BgtUIsbIEv3IS+bccXFWj7tuNb/dqIEW85rI8TY+U43akSpR0hC 4FAT+WvlTCmST9/mhThlgKmzt4zpL+sd23lnqjhBI5Rv5Tm8R5eraFojlo5svh43xnl2 8Pf64A+tfFNcg0cykguzBpIc4brIwHV8lDK/PJPa8LK1aJvZ2pf1QEOoyTeA3Oa6dQvb ZVYTbmN7sOVQTsFloHFiWDSlzCFg+jFhakPZy1TPhh1g7whmveDhrsaW6twwhTNbDWNF RG+B2LSTFs151b/y0+jMvJvyJKIMIvubzwscwyfR6htbEVrRDRpLhu8FZkFw4i018ZLq hL6g== X-Gm-Message-State: AGi0PuZi1jlgyu+o9HZRhnpn8dFt4TVAoVR39Nhlb7OG4y7sm33unrmR 1TfQ7YmD48gixA2NdqURiUs= X-Google-Smtp-Source: APiQypKohd2AEF9JAcTnV9ddAUuiRw6sNd+djAfI62n/4+pZrMZ1dVGR6Hlu2qFOCq/S1NMU94YKSQ== X-Received: by 2002:a0c:ec47:: with SMTP id n7mr19842865qvq.209.1586177158417; Mon, 06 Apr 2020 05:45:58 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a8:1102:88d:4477:a721:6ae4? ([2620:10d:c091:480::1b34]) by smtp.googlemail.com with ESMTPSA id h135sm7382384qke.61.2020.04.06.05.45.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2020 05:45:57 -0700 (PDT) Sender: Nathan Sidwell Subject: Re: [PATCH] Check DECL_CONTEXT of new/delete operators. To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , Jan Hubicka Cc: Richard Biener , GCC Patches , Marc Glisse , Jason Merrill , Jonathan Wakely 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> From: Nathan Sidwell Message-ID: Date: Mon, 6 Apr 2020 08:45:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <0dbc191e-66f7-9878-956d-96149f20f5bf@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Mon, 06 Apr 2020 12:46:01 -0000 On 4/6/20 4:34 AM, Martin Liška 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.' But, I suspect the optimization is safe, in that either no one counts objects by their allocation, or if they do, they don't actually care that the std-conforming number of allocations happen. The both operator new and operator delete are looked up in the same manner. The std does not require a 'matching pair' be found. but it is extremely poor form for a class to declare exactly one of operator {new,delete}. The following is well formed: struct PoorForm { void *operator new (size_t s) {count++; return ::operator new (s)}; static unsigned count; }; Have you considered throwing ctors? struct Obj { Obj (); // might throw }; 'obj = new Obj (); ... delete obj;' sequence expand to something like ... // obj = new Obj (); void *p = ::operator new (sizeof (Obj)); try { Obj::ctor(p); } catch (...) // cleanup code { ::operator delete (p); // #1 throw; } obj = (Obj*)p; .... user code // delete obj; Obj::dtor (obj); ::operator delete (obj); // #2 calls 1 & 2 matchup to the operator new call Notice that para I quoted allows one to coalesce allocations using the global operator new/deletes. The rules are pretty much as you can guess -- one lifetime must be entirely within the other. If inner one's ctor throws, the exception path must destroy the outer. does that help? nathan -- Nathan Sidwell