From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19776 invoked by alias); 24 May 2015 07:51:32 -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 19749 invoked by uid 89); 24 May 2015 07:51:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wg0-f51.google.com Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 24 May 2015 07:51:20 +0000 Received: by wghq2 with SMTP id q2so50137066wgh.1; Sun, 24 May 2015 00:51:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.59.79 with SMTP id x15mr12706350wjq.81.1432453877058; Sun, 24 May 2015 00:51:17 -0700 (PDT) Received: by 10.180.82.133 with HTTP; Sun, 24 May 2015 00:51:17 -0700 (PDT) In-Reply-To: <20150523195252.22647b46@vepi2> References: <20150523195252.22647b46@vepi2> Date: Sun, 24 May 2015 11:25:00 -0000 Message-ID: Subject: Re: [Patch, fortran] PR66079 - [6 Regression] memory leak with source allocation in internal subprogram From: Paul Richard Thomas To: Andre Vehreschild Cc: "fortran@gcc.gnu.org" , gcc-patches , Damian Rouson Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2015-05/txt/msg02211.txt.bz2 Dear Andre, I'll put both points right. Thanks for pointing them out. Cheers Paul On 23 May 2015 at 19:52, Andre Vehreschild wrote: > Hi Paul, > > does this patch apply to current trunk cleanly? I get an issue with the last > hunk, because all of the prerequisites are gone since r223445. The string copy > is completely handled by the trans_assignment at the bottom of the if > (code->expr3) block. Therefore I doubt the patches last hunk is needed any > longer. > > Do you have an example why this hunk is needed? > > Index: gcc/fortran/trans-stmt.c > =================================================================== > *** gcc/fortran/trans-stmt.c (revision 223233) > --- gcc/fortran/trans-stmt.c (working copy) > *************** gfc_trans_allocate (gfc_code * code) > *** 5200,5206 **** > } > /* else expr3 = NULL_TREE set above. */ > } > ! else > { > /* In all other cases evaluate the expr3 and create a > temporary. */ > --- 5200,5207 ---- > } > /* else expr3 = NULL_TREE set above. */ > } > ! else if (!(code->expr3->ts.type == BT_DERIVED > ! && code->expr3->ts.u.derived->attr.alloc_comp)) > { > /* In all other cases evaluate the expr3 and create a > temporary. */ > > When I get the code right, than all derived-typed source= expressions that have > an allocatable component will not be prepared for copy to the allocated object. > This also means, that functions returning an object of such a type are called > multiple times. Once for each object to allocate. Is this really desired? > > I am sorry, that I have to say that, but the check2305.diff file does not bring > the testcase with it. > > Regards, > Andre > > > On Sat, 23 May 2015 14:48:53 +0200 > Paul Richard Thomas wrote: > >> Dear All, >> >> This patch started out fixing a single source of memory leak and then >> went on to fix various other issues that I found upon investigation. >> >> The fortran ChangeLog entry is sufficiently descripive that I do not >> think that there is a need to say more. >> >> Bootstrapped and regtested on x86_64/FC21 - OK for trunk? >> >> I am rather sure that some of the issues go further back than 6.0. I >> will investigate what should be fixed for 5.2. >> >> Cheers >> >> Paul >> >> 2015-05-23 Paul Thomas >> >> PR fortran/66079 >> * trans-expr.c (gfc_conv_procedure_call): Allocatable scalar >> function results must be freed and nullified after use. Create >> a temporary to hold the result to prevent duplicate calls. >> * trans-stmt.c (gfc_trans_allocate): Prevent memory leaks by >> not evaluating expr3 for scalar derived types with allocatable >> components. Fixed character length allocatable results and >> dummies need to be dereferenced. Also, if al_len is NULL use >> memsz for the string copy. >> >> 2015-05-23 Paul Thomas >> >> PR fortran/66079 >> * gfortran.dg/allocatable_scalar_13.f90: New test > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx