This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs
- From: Jeff Law <law at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Martin Sebor <msebor at gmail dot com>
- Cc: Dominik Inführ <dominik dot infuehr at theobroma-systems dot com>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 30 Nov 2017 18:24:45 -0700
- Subject: Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs
- Authentication-results: sourceware.org; auth=none
- References: <8305B5F4-2A96-4698-8C2E-3255658B5C12@theobroma-systems.com> <CAFiYyc2nZ4vSGa5d_ni0km2kwUtyd9+BScrKzxKdbhZV=t6d1g@mail.gmail.com> <20171122103742.GN14653@tucnak> <BC60F078-9257-4E4F-8D94-7C41F7C7B802@theobroma-systems.com> <ec89be92-a232-5e34-e482-493b9babb65b@gmail.com> <20171129083045.GX2353@tucnak>
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ühr wrote:
>>> Thanks for all the reviews! I’ve 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’ve 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.
That's probably a special enough case to be worth a warning
(non-escaping without deallocation).
My comments about needing a stronger analysis engine were for the more
general problem of resource leak detection.
jeff