[PATCH, Fortran, v1] Restructure initialization of allocatable components
Andre Vehreschild
vehre@gmx.de
Thu Nov 3 13:16:00 GMT 2016
Hi all,
the attached patch restructures gfortran's way of initializing components of
derived types in ALLOCATE. The old way was to generate a new gfc_code-node and
add it after the ALLOCATE node to initialize the the derived type on certain
conditions (like initializer or allocatable components exist). This patch
proposes to do the initialization as part of the ALLOCATE. This way it makes the
ALLOCATE-statement more atomic in that the ALLOCATE does everything it is
responsible for itself and does rely on other nodes adding to its
responsibilities. The patch furthermore enables to use the knowledge we have in
the allocate, i.e., a freshly allocated object can never have allocated
allocatable components, so no need to check before resetting them.
At the same time I remove some dead code from the resolve_alloc_expr and moved
a loop invariant piece out of the loop iterating over all objects to allocate.
This of course is only cosmetic.
Of course did I not do this out of fun. I have a patch upcoming for allocatable
components in coarrayed derived types. For this I needed to identify the
initialization of the structure and to parameterize it further. This was hard
when for the default initialization an additional code-node was created, but
now that everything necessary for ALLOCATE is done in ALLOCATE parameterizing
the initialization is way easier. The coarray patch is not yet perfect, but I
thought to publish this part already to get your opinions.
Bootstraps and regtests fine on x86_64-linux/F23. Ok for trunk?
@Dominique: Would you give it a go on your open patch collection? Maybe it
fixes one PR, but I am not very hopeful, because the patch is merely removing
complexity instead of doing new things.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rework_derived_alloc.clog
Type: application/octet-stream
Size: 1296 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20161103/377e4e4f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rework_derived_alloc.patch
Type: text/x-patch
Size: 10023 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20161103/377e4e4f/attachment.bin>
More information about the Fortran
mailing list