From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id D85C9385C019 for ; Tue, 7 Apr 2020 10:22:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D85C9385C019 Received: by mail-lf1-x143.google.com with SMTP id h6so1973529lfc.0 for ; Tue, 07 Apr 2020 03:22:59 -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; bh=ajxxCQ/JHHVULiJzPoTQFTVco2G6xwlX/lPuPmPVR8g=; b=bq1/EK/KptD5c6gL3s2QiJGFqfVzWNckCwB6+Mk46wfqWfPKsi2QoNh/8cZY4FsAEC FwB1FbNr2jQUWWM+nOeaaCZWRN/YmCjgf8pDjkbdE3oJ/IX/d51uu+a+kKrEcRoFCvwS +LYGtkszIuzkxaHDP5nmrM/RjrOMNZ8bYOCCaeli4Rw7kphGuFlcRpv0F5waarQqD6fi AEO5q/LMJhxtfldcbEHQ+6pmKso6nWr6nTnBKXcTr+Fht/GIt8sMRGm9pXb5+i8QW47M INVKPlJY9mKtMsaVXKRqmTX6Fz2HfeXiIHByWa/6rzmW7FnN8UXpP1Q+uk1ZL5h0kmjR MOyg== X-Gm-Message-State: AGi0PubI/yvl/6vrXuRE5a4GDdTVLLtjCz0Pp9zJpv0+wx5II3BJfI/V bMvuhRTymQY/d0u/3t+1zkZuJfJGqfx2EhY39SM= X-Google-Smtp-Source: APiQypI14himV9nvkGAoARR8N8L6jVEGQ5tqm2zmwxe8DvRGM5bFhMr4F9tb+mblMKsi3Qg5mdrSxUtzGl0gM+7hYqs= X-Received: by 2002:ac2:5f63:: with SMTP id c3mr1097651lfc.15.1586254978423; Tue, 07 Apr 2020 03:22:58 -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> <20200407094937.GC8012@kam.mff.cuni.cz> In-Reply-To: <20200407094937.GC8012@kam.mff.cuni.cz> From: Richard Biener Date: Tue, 7 Apr 2020 12:22:46 +0200 Message-ID: Subject: Re: [PATCH] Check DECL_CONTEXT of new/delete operators. To: Jan Hubicka Cc: Jonathan Wakely , Nathan Sidwell , =?UTF-8?Q?Martin_Li=C5=A1ka?= , GCC Patches , Marc Glisse , Jason Merrill Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 10:23:01 -0000 On Tue, Apr 7, 2020 at 11:49 AM Jan Hubicka wrote: > > > > > 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). > I was just arguing that comparing pointers to types does not make much > sence in LTO where types can get unshared :) > Since the classes have ODR name at least this problem can be solved by > using ODR name compare. Sure. > However the testcase I sent abuses the fact that if you inherit the > class you can rewrite only new operator. In the inerited class > DECL_CONTEXT of delete will still point to the oriignal class. This > means that you can mix new/delete pair from the original and inherited > class. Yeah, but we're searching for a correctness fix not for an optimality one ;) It sounds matching up the pairs in the middle-end is impossible and thus the FE has to do this match-up (or refrain from marking new/delete when a matchup according to to be defined methods is not going to be enough). And maybe that tracking has to be done on a per call level rather than on a called function level. Richard. > Honza > > > > 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.