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 9D435385B835 for ; Thu, 9 Apr 2020 08:05:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9D435385B835 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,362,1580770800"; d="scan'208";a="345456678" 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; 09 Apr 2020 10:04:47 +0200 Date: Thu, 9 Apr 2020 10:04:47 +0200 (CEST) From: Marc Glisse X-X-Sender: glisse@stedding.saclay.inria.fr To: Richard Biener cc: =?ISO-8859-15?Q?Martin_Li=A8ka?= , Jason Merrill , Jakub Jelinek , Jonathan Wakely , Jan Hubicka , GCC Patches , Nathan Sidwell Subject: Re: [PATCH] Allow new/delete operator deletion only for replaceable. In-Reply-To: Message-ID: References: <20200403152609.GA35629@kam.mff.cuni.cz> <0dbc191e-66f7-9878-956d-96149f20f5bf@suse.cz> <20200408133252.GG2212@tucnak> <20d175a6-23df-43e5-7027-d11fc660abd1@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.7 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: Thu, 09 Apr 2020 08:05:26 -0000 On Thu, 9 Apr 2020, Richard Biener wrote: > On Thu, Apr 9, 2020 at 7:06 AM Martin Liška wrote: >> >> Hi. >> >> We've got one another sneaky test-case (thank you Marc ;) ): >> >> $ cat pr94314-array.C >> #include >> #include >> >> int count = 0; >> >> __attribute__((malloc, noinline)) void* operator new[](unsigned long sz) { >> ++count; >> return ::operator new(sz); >> } >> >> void operator delete[](void* ptr) noexcept { >> --count; >> ::operator delete(ptr); >> } >> >> void operator delete[](void* ptr, std::size_t sz) noexcept { >> --count; >> ::operator delete(ptr, sz); >> } >> >> int main() { >> delete[] new int[1]; >> if (count != 0) >> __builtin_abort (); >> } >> >> I bet we need to include the Honza's fix for inline stacks. >> Or it the test-case invalid? > > I don't see how inline stacking helps here when you consider > > void *foo(unsigned long sz) { return ::operator new(sz); } > void operator delete[](void* ptr) noexcept { > --count; > ::operator delete(ptr); > } > > thus regular functions inlining where definitely the inline > stack depth does not need to match. > > I guess the testcase asks for us to match the exact > operator form (in the testcase we match ::delete and ::new[]), > for example by instead of looking at the decl flags > simply match the assembler names (the mangled names) > of the operator? A hard-coded list can make sense (although if we use asm names, I guess we have to take care of platforms that prefix all symbols with _ for instance). 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. Not sure about the nothrow versions... -- Marc Glisse