From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100521 invoked by alias); 28 Jul 2018 16:37:16 -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 100500 invoked by uid 89); 28 Jul 2018 16:37:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=one, Should, HX-Received:sk:11-v6mr, H*f:CAGkQGi X-HELO: mail-yw0-f181.google.com Received: from mail-yw0-f181.google.com (HELO mail-yw0-f181.google.com) (209.85.161.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 28 Jul 2018 16:37:14 +0000 Received: by mail-yw0-f181.google.com with SMTP id r3-v6so2986148ywc.5; Sat, 28 Jul 2018 09:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Wwm9Jj2q05uyTsgzP1vFxofrPvay3IFwsceM2IN1DE8=; b=bvu0bVHrIny9xdLuQdgFtWgA3gI68lMYZM+eRBd6TELIzwGhORgvnqq5Le9bA5mbvJ 9t4ravohs7MoEDRs/h/7IDKb3e7MWfDjmKtAqjp2KYHB5TLjSNb4s8br7kXYjWwE0dyw TSOW9TNGhhLrrRxe2Pz2Vu5FIxwHOX4wFkFty2KArc1IJIVayMKl6izZS4Hit1C1p3GD YzKb7YHE5wI+l5pXObiANseJptWCetPQjBQIM+Chl3yYoh4EdhviMMfsyqeJnKclM98+ m7Az9JWVtMH5ycLunA/mPPsXY9aW5UO+nnhYJY6gs9xhK6te3KfnY+tqMIlj/Mm62L7a BNTw== MIME-Version: 1.0 Sender: jaydub66@gmail.com Received: by 2002:a0d:ea0c:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 09:37:12 -0700 (PDT) In-Reply-To: References: From: Janus Weil Date: Sat, 28 Jul 2018 16:37:00 -0000 Message-ID: Subject: Re: [Patch, fortran] PR80477 - [OOP] Polymorphic function result generates memory leak To: Paul Richard Thomas Cc: "fortran@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-07/txt/msg01792.txt.bz2 Hi Paul, 2018-07-28 9:32 GMT+02:00 Paul Richard Thomas : > Several attempts, including mine, were made to fix this bug since it > was posted. They were all attacking the wrong place. Instead of > providing the free of the class _data as part of the call to > 'add_a_type' it should be included in the post block of the argument > processing in the call to 'assign_a_type'. The comment in the patch > says the rest. > > Bootstrapped and regtested on FC28/x86_64 - OK for trunk? great that you managed to solve this one! The patch looks very good to me, but I'm afraid two details may be missing: 1) If the type has allocatable components, those need to be freed first. 2) If the type has a finalizer, that needs to be called as well. I believe that both points can be fixed by calling the _final component of the vtab before freeing the class data. Should not be hard to add, I hope (gfc_add_finalizer_call might be useful). Thanks for your efforts ... Cheers, Janus