From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 4E8F1394505B for ; Mon, 6 Apr 2020 15:10:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4E8F1394505B Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-187-c2owIc2hNIukZu68VmaaEA-1; Mon, 06 Apr 2020 11:10:15 -0400 X-MC-Unique: c2owIc2hNIukZu68VmaaEA-1 Received: by mail-il1-f200.google.com with SMTP id w76so15390489ila.6 for ; Mon, 06 Apr 2020 08:10:15 -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=wMCIHcZeHl+hQJhmqyEBmgnGqiZt2N3Llgt1UVKtkT0=; b=bMetSAqP/L70B1sBNVAuPI+SED7PAqtlUVfLcnnW0BHIkx+fI4oRXJHZpWVWi/GlKF XGsXJ3YxDXYIZ4gBerI/lghHVxwqmVMYJW9I5SlpUwiat11T9TSMpP+oTFhv7U4NkDpx 9mDqUJr6mnckCmBL/rO79U8K5o8O039+uJWI8UaFGgKfTmufqJFgP1hvNTcaVaKLvYpm xZBQM2lZKt2v83GnyThqUNjUVwnG07/H79oTf394IC3Isi/NHppvlTHV768vpNRkVGMk xcQM+F+OQn+kfMqmH8JWv3Fsj/I5aOSoZMWfxuNGmDxNfuqPpwEhHVpGQ8eGo0ERGixi ovcA== X-Gm-Message-State: AGi0PuZbCZq4kAz4sec7ayTlpFUNMKuR9AC10Wk9xo+ifHIZwlSS5AYV tLNcQfHyMT86AcN24cLM1xMdxZQdBqdvtukZQfUYvaEk2SRYNfPjlmleevOyJL6Qt8L5iGREit3 r03TPGMzSEPnNeikuvp3bwDRfsyhQnx7YNg== X-Received: by 2002:a6b:b7d8:: with SMTP id h207mr3374159iof.138.1586185813831; Mon, 06 Apr 2020 08:10:13 -0700 (PDT) X-Google-Smtp-Source: APiQypJNoeIONSkJcM8MuCkgzJvqCNe5T1BHj6JSwAs1NaGiBYi1K5/Da/5DSN7ihdYKDD2FxYd3veGWt+sI6vclcaw= X-Received: by 2002:a6b:b7d8:: with SMTP id h207mr3374130iof.138.1586185813459; Mon, 06 Apr 2020 08:10:13 -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> <20200403154212.GB35629@kam.mff.cuni.cz> <20200404115313.GA26608@kam.mff.cuni.cz> In-Reply-To: From: Jason Merrill Date: Mon, 6 Apr 2020 11:10:02 -0400 Message-ID: Subject: Re: [PATCH] Check DECL_CONTEXT of new/delete operators. To: Richard Biener Cc: Jan Hubicka , GCC Patches , Marc Glisse X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 15:10:19 -0000 On Mon, Apr 6, 2020 at 5:27 AM Richard Biener via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka wrote: > > > > Hi, > > thinking a bit of the problem, I guess we could match in addition to > > DECL_CONTEXT the whole inline stack of both statements and see if there > > are inlined new/delete operators and if so if they are always in > > matching pairs. > > > > The inline stack is available as > > for (tree block =3D gimple_block (call); block && TREE_CODE (block) =3D= =3D > BLOCK; block =3D BLOCK_SUPERCONTEXT (block)) > > { > > tree fn =3D block_ultimate_origin (block); > > if (fn !=3D NULL && TREE_CODE (fn) =3D=3D FUNCTION_DECL) > > do the checking htere. > > } > > > > But I do not understand what C++ promises here and in what conditions > > the new/delete pair can be removed. > > But if the inline stack matches in pairs then the ultimate new/delete > call should also > match, no? When there's a mismatch in inlining we can't DCE since we > can't remove > the extra inlined stmts. > > Your failing testcase suggests we never can remove new/delete pairs thoug= h > unless the DECL_CONTEXT is 'final'. Also the user could have chosen to > "inline" the side-effect of the new operation manually but not the > delete one, so > > operator delete() { count-- } > > ptr =3D new A; > count++; > delete ptr; > > is it valid to elide the new/delete pair here? > The C++ constraints are (deliberately, I think) vague. As Nathan quotes, it just says that a call to a replaceable operator new can be omitted, and that if it is, the matching delete-expression should not call operator delete. This example seems to demonstrate that we should also only consider the replaceable delete operators, not any operator delete. Jason