This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch, fortran] PR34820 , PR34143 and PR32795 - some allocatable component bugs

:ADDPATCH fortran:

These are fixes for the outstanding PRs associated with allocatable
components.  They all provide code that works but I have to check
whether there is any residual memory leakage or not.  Unfortunately,
the code becomes so complicated that it is more or less impossible to
track the mallocs and frees.  I will try to use FX´s patch to do the

This was concerned with the behaviour of intent out derived types with
allocatable components.  Specifically, arrays of such derived types,
if passed as automatic arrays, caused an ICE.  This came about because
the nullification was done in the aller, instead of the callee, so
that the bounds were not known.  This could have been resolved with
the interface procedures but it was easier to move it over to the
callee side.  This has a consequence for alloc_comp_basics_1.f90
because it is anticipating builtin_free's for each call, rather than
each procedure.  Thus it has to be corrected.  The testcase is
essentially the reporter's.

This was a rather simple matter of catching implicit conversions,
resulting from -fdefault-integer-8, when the expression being
converted is NULL.  It raises a standard question about allocatable
components in general; should they be justified to lbound = 1, lbound
= 0, lbound = ??? or not justified at all?  The testcase is
essentially the reporter's.

This has already been submitted and okayed for 4.4.  gfortran tried to
nullify variable arguments to derived type constructors with
allocatable components, causing the ICE and/or memory leakage that
might be expected.  The testcase is a convenient borrowing from some
of the discussion in the PR.  I understand that the memory leakage
associated with this PR has not been fixed.  I will investigate this
and submit a further patch.

Bootstrapped and regtested on Cygwin_NT/amd64 (and on x86_ia64/FC8,
when I get home) - OK for trunk?


2008-02-22  Paul Thomas  <>

	PR fortran/34820
	* trans-expr.c (gfc_conv_function_call): Remove all code to
	deallocate intent out derived types with allocatable
	(gfc_trans_assignment_1): An assignment from a scalar to an
	array of derived types with allocatable components, requires
	a deep copy to each array element and deallocation of the
	converted rhs expression afterwards.
	* trans-array.c : Minor whitespace.
	* trans-decl.c (init_intent_out_dt): Add code to deallocate
	allocatable components of derived types with intent out.

	PR fortran/34143
	* trans-expr.c (gfc_trans_subcomponent_assign): If a conversion
	expression has a null data pointer argument, nullify the
	allocatable component.

	PR fortran/32795
	* trans-expr.c (gfc_trans_subcomponent_assign): Only nullify
	the data pointer if the source is not a variable.

2008-02-22  Paul Thomas  <>

	PR fortran/34820
	* gfortran.dg/alloc_comp_constructor_6.f90 : New test.
	* gfortran.dg/alloc_comp_basics_1.f90 : Reduce expected refs to
	'builtin_free' from 24 to 18.

	PR fortran/34143
	* gfortran.dg/alloc_comp_constructor_5.f90 : New test.

	PR fortran/32795
	* gfortran.dg/alloc_comp_constructor_4.f90 : New test.

Attachment: submit.diff
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]