[Patch, fortran] PR20541 - allocatable components (TR15541)

[Paul Thomas]

:ADDPATCH:
 
This patch implements the part of TR15541 that is concerned with 
allocatable components of derived types.  This extension to the F95 
standard offers three important advantages over pointer components:
 
(i) Automatic deallocation of memory upon going out of scope;
(ii)The automatic handling of allocation and copying of data in 
assignements of derived types with allocatable components; and
(iii) Performance advantages through the automatic transfer of allocated 
resources.
 
In the end, we have concentrated on (i) and (ii) and rather less on 
(iii).  This is a starting point and it will be worthwhile looking for 
opportunities to avoid copying and freeing, which undoubtedly occurs at 
present.
 
The reason for (i) and (ii) is to ensure automatically that there is no 
memory leakage. To the best of our ability, we have checked that this is 
so but would appreciate users supplying us with evidence to the contrary.
 
It was not entirely intended, at the start, that the bulk of the patch 
be in the translation stage.  Instead, we had the idea that some master 
library functions could do most of the work.  This initial idea was not 
overthrown by plan but rather because the initial demonstrations of 
feasibility and the establishment of the framework all were done in 
trans-XXXX.c. One area that could be improved, by returning to the 
original concept, is that of deallocation on leaving scope.  It would be 
effective to traverse a list of allocated resources, rather than 
checking all the allocatable components, whether allocated or not.  
Equally though, since the code is all inline it is quite quick.
 
The patch has become rather substantial for which we apologise to the 
reviewer(s).  If it is any consolation, neither of us would have started 
upon this project had we appreciated what would be involved!
 
It should be noted that a couple of other PRs have been cleared up in 
the course of developing this patch and that several incipient but 
unreported problems have also been dealt with. These are:
 
(i) PR29098, which involves ICEs resulting from default initializers 
with components that are not set
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00671.html (Fixed on trunk);
(ii) PR29211, which is associated with character assignments with 
depencies, in FORALL statements or blocks, causing ICEs (Bundled in here);
(iii) Derived type constructors with array components had no checks for 
compliance, even of rank - ie. the constructor elements should either be 
scalar of have the same rank as the component;
(iv) A failure of derived type association (groan!) that seems to be 
specific to derived types with allocatable components had to be sorted 
out; and
(v) The F2003 intrinsic MOVE_ALLOC has been implemented.

PR29115 was uncovered and fixed in the course of rather intensive work 
on derived type constructors - it is also included here because it 
became intimately intermingled with the main patch
 
Much of the patch consists of fairly mundane housekeeping or enabling 
bits and pieces. It is not really worth covering those here and you are 
referred to the patch, the ChangeLog and the patched code for these, 
since they are relatively simple and clear.
 
The major action occurs in trans-array.c, trans-decl.c and trans-expr.c:
 
(i) trans-array.c
 
The patch to this file is mostly associated with the deallocation, 
nullification and copying of derived types with allocatable components. 
Life is made relatively easy by the arrays being whole and packed. Thus, 
obtaining the size of and accessing all the components of the 
allocatable arrays is very straight forward.
 
Three interface functions call a single multi-purpose, recursive 
function structure_alloc_comps.  This has to be recursive to handle 
components that are themselves derived types with allocatable 
components.  The code branches between scalars and arrays.  The latter 
are handled using a helper function to obtain the array size and 
looping, to make recursive calls to treat the allocatable components, 
using bits of the scalarizer.  The scalar section does the actual 
business of deallocation, nullification and copying.
 
The rest of the modifications to this file are relatively minor.
 
(ii) trans-decl.c
 
The code modification to this file is small.  Instead much of the 
marshalling of the derived types with allocatable components is done 
here; specifically by adding these beasts to the list of 
"deferred_variables", which marks them for automatic nullifcation and 
deallocation, on scope entry and exit. Similarly nullification of 
function results with allocatable components is done here.
 
(iii) trans-expr.c
 
This file contains nearly all the modifications needed for assignement 
and derived type constructors.  These modifications are all associated 
with memory management; ensuring that the resources are copied or 
transferred, as necessary.
 
The handling of assignments requires the addition of an extra block 
within gfc_trans_scalar_assign and two new arguments.  Under the control 
of these latter, which indicate that the lhs is a temporary or the rhs 
is a variable, deallocation of the lhs and copying/transfer of the rhs 
data are done.
 
As well as the assignment calls form within trans-expr.c, trans-stmt.c 
is a big user because of the special ssignments made within FORALL and 
WHERE blocks.
 
 
The testsuite additions check most of the major features of allocatable 
components, although we have no doubt that future PRs in this are will 
expose the need for more!  They are all commented as to their purpose 
and serve as a useful template of the capabilities of this extra feature.
 
 
The patch has been extensively tested and we thank Salvatore Filippone 
and Steve Kargl for their efforts; Salvatore for doing his best as the 
"Patch Buster"(We'll have to buy him a 50's Buick... ) and Steve for 
checking that allocatable components do not break anything else. We are 
grateful to a number of the other "usual suspects", such as Jerry 
DeLisle and Jack Howarth, who have added vocal support and tests over a 
range of platforms.
 
It is important to realise that this patch is mostly insulated from the 
rest of Fortran95, behind if statements that require objects with 
allocatable components.  We are reasonably sure, thanks to Steve's and 
our own efforts, that we have tested that this is the case.  However, 
uttering that thought is an invitation to be proven wrong!  The most 
serious breach of this "insulation" is the small change to derived type 
association in trans_types.c.  After the previous experience, one of us 
will be watching this part like a hawk!
 
Steve has suggested an extra compiler option to go with -std=f95; add an 
-fenable-tr15541 option.  We will undertake to do this but not right 
away; we have to get reaquainted with our families and friends.
 
We hope that this extension proves to be useful and that the bugs that 
are almost certainly there will trickle in at a managable pace!
 
Regtested a silly number of times on a wide range of platforms and OS's 
(in the last 24 hours: SUSE10.1/AMD64, FC5/Athlon1700 and Cygwin_NT/PIV) 
- OK for trunk?
 
Phew!
 
Erik and Paul

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ChangeLog
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20061005/6caed39e/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: submit.diff
Type: text/x-patch
Size: 102898 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20061005/6caed39e/attachment.bin>