From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106252 invoked by alias); 8 Jul 2019 22:20:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 106186 invoked by uid 89); 8 Jul 2019 22:20:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jul 2019 22:20:49 +0000 Received: from 85-171-188-236.rev.numericable.fr (HELO stedding) ([85.171.188.236]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2019 00:20:47 +0200 Date: Tue, 09 Jul 2019 02:28:00 -0000 From: Marc Glisse To: =?ISO-8859-15?Q?Martin_Li=A8ka?= cc: Richard Biener , gcc-patches@gcc.gnu.org, David Malcolm , dominik.infuehr@theobroma-systems.com, Jason Merrill , Nathan Sidwell Subject: Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl. In-Reply-To: <70688da3-caf4-53c1-d0ee-63d16cbaadd9@suse.cz> Message-ID: References: <8305B5F4-2A96-4698-8C2E-3255658B5C12@theobroma-systems.com> <20171122103742.GN14653@tucnak> <20171129083045.GX2353@tucnak> <1511972121.27881.39.camel@redhat.com> <0dd24714-1f35-6a80-c607-7c8a332e95b9@suse.cz> <9D090495-3C97-4873-B0DF-2610B478F621@gmail.com> <70688da3-caf4-53c1-d0ee-63d16cbaadd9@suse.cz> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-SW-Source: 2019-07/txt/msg00631.txt.bz2 On Mon, 8 Jul 2019, Martin Liška wrote: >> The patch apparently has DECL_IS_OPERATOR_DELETE only on the >> replaceable global deallocation functions, not all delete operators, >> contrary to DECL_IS_OPERATOR_NEW, so the name is misleading. On the >> other hand, those seem to be the ones for which the optimization is >> legal (well, not quite, the rules are in terms of operator new, and I >> am not sure how well operator delete has to match, but close enough). > > Are you talking about this location where we set OPERATOR_NEW: > https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/decl.c#L13643 > ? > > That's the only place where we set OPERATOR_NEW flag and not OPERATOR_DELETE. Yes, I think that's the place. Again, not setting DECL_IS_OPERATOR_DELETE on local operator delete seems misleading, but setting it would let us optimize in cases where we are not really allowed to. Maybe just rename your macro to DECL_IS_GLOBAL_OPERATOR_DELETE? -- Marc Glisse