From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 96576385B835 for ; Fri, 10 Apr 2020 08:37:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 96576385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=marc.glisse@inria.fr X-IronPort-AV: E=Sophos;i="5.72,366,1580770800"; d="scan'208";a="345576653" Received: from 225.95.12.109.rev.sfr.net (HELO stedding) ([109.12.95.225]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2020 10:37:14 +0200 Date: Fri, 10 Apr 2020 10:37:09 +0200 (CEST) From: Marc Glisse X-X-Sender: glisse@stedding.saclay.inria.fr To: =?ISO-8859-15?Q?Martin_Li=A8ka?= cc: Jonathan Wakely , Richard Biener , Jason Merrill , Jakub Jelinek , Jan Hubicka , GCC Patches , Nathan Sidwell Subject: Re: [PATCH] Allow new/delete operator deletion only for replaceable. In-Reply-To: <8cac5c65-3b93-1c9a-87e9-9e42eb876eba@suse.cz> Message-ID: References: <20200403152609.GA35629@kam.mff.cuni.cz> <20200408133252.GG2212@tucnak> <20d175a6-23df-43e5-7027-d11fc660abd1@suse.cz> <8cac5c65-3b93-1c9a-87e9-9e42eb876eba@suse.cz> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Fri, 10 Apr 2020 08:37:17 -0000 On Fri, 10 Apr 2020, Martin Liška wrote: > On 4/9/20 10:13 AM, Jonathan Wakely wrote: >> On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote: >>> Note that the matching is not 1-to-1. Array vs non-array and >>> aligned vs non-aligned seem important, but sized and unsized delete can >>> both match the same new, IIUC. >> >> Right. >> >>> Not sure about the nothrow versions... >> >> This is valid, and mixes the nothrow new with non-nothrow delete: >> >> delete new (std::nothrow) int; >> > > All right, there's a patch candidate that comes up with the list of possible > pairs. > For better readability, I present demangled names: > > $ cat /tmp/pairs.txt | c++filt > "operator new(unsigned long):operator delete(void*)" , > "operator new(unsigned long):operator delete(void*, unsigned long)" > , > "operator new(unsigned long):operator delete(void*, std::nothrow_t > const&)" , > "operator new(unsigned long, std::nothrow_t const&):operator > delete(void*)" , > "operator new(unsigned long, std::nothrow_t const&):operator > delete(void*, unsigned long)" , > "operator new(unsigned long, std::nothrow_t const&):operator > delete(void*, std::nothrow_t const&)" , > /* non-[] operators with alignment. */ > "operator new(unsigned long, std::align_val_t):operator > delete(void*, unsigned long, std::align_val_t)" , > "operator new(unsigned long, std::align_val_t):operator > delete(void*, std::align_val_t)" , > "operator new(unsigned long, std::align_val_t):operator > delete(void*, std::align_val_t, std::nothrow_t const&)" , > "operator new(unsigned long, std::align_val_t, std::nothrow_t > const&):operator delete(void*, unsigned long, std::align_val_t)" , > "operator new(unsigned long, std::align_val_t, std::nothrow_t > const&):operator delete(void*, std::align_val_t)" , > "operator new(unsigned long, std::align_val_t, std::nothrow_t > const&):operator delete(void*, std::align_val_t, std::nothrow_t const&)" , > /* [] operators. */ > "operator new[](unsigned long):operator delete[](void*)" , > "operator new[](unsigned long):operator delete[](void*, unsigned > long)" , > "operator new[](unsigned long):operator delete[](void*, > std::nothrow_t const&)" , > "operator new[](unsigned long, std::nothrow_t const&):operator > delete[](void*)" , > "operator new[](unsigned long, std::nothrow_t const&):operator > delete[](void*, unsigned long)" , > "operator new[](unsigned long, std::nothrow_t const&):operator > delete[](void*, std::nothrow_t const&)" , > /* [] operators with alignment. */ > "operator new[](unsigned long, std::align_val_t):operator > delete[](void*, unsigned long, std::align_val_t)" , > "operator new[](unsigned long, std::align_val_t):operator > delete[](void*, std::align_val_t)" , > "operator new[](unsigned long, std::align_val_t):operator > delete[](void*, std::align_val_t, std::nothrow_t const&)" , > "operator new[](unsigned long, std::align_val_t, std::nothrow_t > const&):operator delete[](void*, unsigned long, std::align_val_t)", > "operator new[](unsigned long, std::align_val_t, std::nothrow_t > const&):operator delete[](void*, std::align_val_t)", > "operator new[](unsigned long, std::align_val_t, std::nothrow_t > const&):operator delete[](void*, std::align_val_t, std::nothrow_t const&)", > > Marc pointed out that some targets do not use the leading '_' (or use 2 > dashes?) for mangled named? > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. How do you handle platforms where size_t is not unsigned long? -- Marc Glisse