From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118698 invoked by alias); 29 Nov 2017 16:53:27 -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 118688 invoked by uid 89); 29 Nov 2017 16:53:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_3,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Nov 2017 16:53:25 +0000 Received: by mail-wm0-f67.google.com with SMTP id i11so7259804wmf.4 for ; Wed, 29 Nov 2017 08:53:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=34GjUQd2dwGCyfQYM9E3J0w633IIXaDBLdV+tFJ3cnk=; b=C4TkGYGtFnFyQFDtOQMIqXr12xUDOkvGQMV62BqBa/29bgk8u5Mb9Tv3t94M5MQEA2 QS2BFIRhrpa5WkHiIfe/+3nhbTpJHhrB3si/dFOCmYi0Fnmg82yuCMhQCh91unXRSl8l 4hAty+mRvxBAifb7vj0ESAjKN+q38H93k3Pj2/T6YZw1NZeeYZNFbx54h1MTv14JzKpq 7SWoZDLKdEjCDpignQHgNZU3jYdTbgNRf9Bb/AFQZHfv+4tkGeUH20tDsitfXggSdvO8 W8uCbLxyj8y6FEI2bdzo4sFUm3P1EbI9yK2v/jDXkl78yGvN4Jw/Gi5CEFOlKerja143 rmfw== X-Gm-Message-State: AJaThX4boVtu4/Jcit1kVP9gnyUL4T7vBlcXWBeh7chW3UAp2QF5sWCc F2jX29RfxtWAwcEquUrYId0= X-Google-Smtp-Source: AGs4zMY3P3DhjXskfOP5wDoxIDt4+gxCDIuq+0+uXQDBpfkki2Lwz9eECj4zjZvJ6RygIluXXu6PsQ== X-Received: by 10.28.150.20 with SMTP id y20mr2784897wmd.118.1511974402265; Wed, 29 Nov 2017 08:53:22 -0800 (PST) Received: from android-97b5c0ce9bfced28.fritz.box (p5DCEC1E9.dip0.t-ipconnect.de. [93.206.193.233]) by smtp.gmail.com with ESMTPSA id n12sm3143432wrn.76.2017.11.29.08.53.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 08:53:20 -0800 (PST) Date: Wed, 29 Nov 2017 18:05:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: References: <8305B5F4-2A96-4698-8C2E-3255658B5C12@theobroma-systems.com> <20171122103742.GN14653@tucnak> <20171129083045.GX2353@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs To: Martin Sebor ,Jakub Jelinek CC: =?ISO-8859-1?Q?Dominik_Inf=FChr?= ,GCC Patches From: Richard Biener Message-ID: X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg02505.txt.bz2 On November 29, 2017 4:56:44 PM GMT+01:00, Martin Sebor = wrote: >On 11/29/2017 01:30 AM, Jakub Jelinek wrote: >> On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote: >>> On 11/27/2017 02:22 AM, Dominik Inf=C3=BChr wrote: >>>> Thanks for all the reviews! I=E2=80=99ve revised the patch, the >operator_delete_flag is now stored in tree_decl_with_vis (there already >seem to be some FUNCTION_DECL-flags in there). I=E2=80=99ve also added the >option -fallocation-dce to disable this optimization. It bootstraps and >no regressions on aarch64 and x86_64. >>>> >>> It's great to be able to eliminate pairs of these calls. For >>> unpaired calls, though, I think it would be even more useful to >>> also issue a warning. Otherwise the elimination will mask bugs >> >> ?? I hope you're only talking about allocation where the returned >> pointer can't leak elsewhere, doing allocation in one function >> (e.g. constructor, or whatever other function) and deallocation in >some >> other one is so common such a warning would be not just useless, but >> harmful with almost all occurrences being false positives. >> >> Warning on malloc/standard operator new or malloc/realloc-like >function >> when the return pointer can't escape the current function is >reasonable. > >Yes, warn for leaks, or for calls to delete/free with no matching >new/malloc (when they can be detected). > > From the test case included in the patch, warn on the first two >of the following three functions: > >+++ b/gcc/testsuite/g++.dg/cpp1y/new1.C >@@ -0,0 +1,65 @@ >+/* { dg-do compile } */ >+/* { dg-options "-O2 -fdump-tree-cddce-details" } */ >+ >+#include >+ >+void >+new_without_use() { >+ int *x =3D new int; >+} >+ >+void >+new_array_without_use() { >+ int *x =3D new int[5]; >+} >+ >+void >+new_primitive() { >+ int *x =3D new int; >+ delete x; >+} > >An obvious extension to such a checker would then be to also detect >possible invalid deallocations, as in: > > void f (unsigned n) > { > void *p =3D n < 256 ? alloca (n) : malloc (n); > // ... > free (p); > } > >David Malcolm was working on something like that earlier this year >so he might have some thoughts on this as well. Or P =3D new x; Free (P) ; Richard.=20 >Martin