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 <paul.richard.tho...@gmail.com> 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 <pa...@gcc.gnu.org> > > 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 <pa...@gcc.gnu.org> > > PR fortran/66079 > * gfortran.dg/allocatable_scalar_13.f90: New test -- Andre Vehreschild * Email: vehre ad gmx dot de