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
