InitializeClone(), implemented in #120295, was not handling top
level pointers and allocatables correctly.
Pointers and unallocated variables must be skipped.
This caused some regressions in the Fujitsu testsuite:
https://linaro.atlassian.net/browse/LLVM-1488
Allocatable members of privatized derived types must be allocated,
with the same bounds as the original object, whenever that member
is also allocated in it, but Flang was not performing such
initialization.
The `Initialize` runtime function can't perform this task unless
its signature is changed to receive an additional parameter, the
original object, that is needed to find out which allocatable
members, with their bounds, must also be allocated in the clone.
As `Initialize` is used not only for privatization, sometimes this
other object won't even exist, so this new parameter would need
to be optional.
Because of this, it seemed better to add a new runtime function:
`InitializeClone`.
To avoid unnecessary calls, lowering inserts a call to it only for
privatized items that are derived types with allocatable members.
Fixes https://github.com/llvm/llvm-project/issues/114888
Fixes https://github.com/llvm/llvm-project/issues/114889
Spread, reshape, pack, and other transformational intrinsic runtimes are
using `CopyElement` utility to copy elements. This utility was dealing
with deep copies, but only when the allocatable components where
"immediate" components of the type being copied. If the allocatable
components were nested inside a nonpointer/nonallocatable component,
they were not deep copied, leading to bugs later when manipulating the
value (or double free when applying #81117).
Visit data components with allocatable components (using the
noDestructionNeeded flag to avoid expensive and useless type visit when
there are no such components).
The runtime was currently only deallocating the direct allocatable
components, which caused leaks when there are allocatable components
nested in the direct components.
Update Destroy to recursively destroy components.
Also call Destroy from Assign to deallocate nested allocatable
components before doing the assignment as required by F2018 9.7.3.2
point 7.
This lack of deallocation was visible if the nested components had user
defined assignment "observing" the allocation state.
Finalize/Initialize may be called on non contiguous arrays when dealing
with INTENT(OUT) dummies or non contiguous LHS. Update the related
element access to use indices instead of assuming contiguity and
manually computing the byte offset.
Also, the descriptor passed to parent type final routines should be set
to the parent type, otherwise descriptor.IsContiguous() may wrongfully
return true when finalizing parent components. Create a pointer to the
parent component when recursing in Finalize.
Previous code was finalizing polymorphic components according to static
type (calling the static type final routine, if any).
There is no way (I think) to know from a
Fortran::runtime::typeInfo::Component if an allocatable component is
polymorphic or not. So this patch just always uses the dynamic type
descriptor to check for derived type allocatable component finalization.
When a FINAL subroutine is being invoked for a discontiguous array, which can
happen for INTENT(OUT) dummy arguments and for some left-hand side variables
in intrinsic assignment statements, it may be the case that the subroutine
being called was defined with a dummy argument that requires contiguous data.
Extend the derived type descriptions used by the runtime to signify when
a special procedure binding requires contiguity; set the flags accordingly;
check them in the runtime support library, and, when necessary, use a
temporary shallow copy of the finalized array data in the call to the
final subroutine.
Differential Revision: https://reviews.llvm.org/D156760
When creating a temporary for conflicting LHS and RHS we have to deep copy
the dynamic (allocatable, automatic) components from RHS to the temp.
Otherwise, the conflict may still be present between LHS and temp.
gfortran/regression/alloc_comp_assign_1.f90 is an example where the current
runtime code produces wrong result:
7b5b5dcbf9/Fortran/gfortran/regression/alloc_comp_assign_1.f90 (L50)
Reviewed By: klausler, tblah
Differential Revision: https://reviews.llvm.org/D156364
Pointer components without default initialization pose some
difficult (or impossible) problems when they appear as right-hand
side targets in pointer assignment statements; they may contain
garbage or stale data that looks enough like a valid descriptor
to cause a crash. Solve the problem by avoiding it -- ensure
that pointers' descriptors are at least minimally established.
Differential Revision: https://reviews.llvm.org/D149979
In the calculation of derived type component byte sizes, ensure
that CLASS(*) unlimited polymorphic components have space allocated
for their addenda.
Differential Revision: https://reviews.llvm.org/D145248
Derived type `Destroy` function does not take step into consideration
when indexing the component element for deallocation. This leads to
incorrect deallocation in case like:
```
module mod1
type :: t
real, allocatable :: r(:)
end type
contains
subroutine do_smth(c)
class(t), intent(out) :: c(:)
do i = 1, size(c)
if (allocated(c(i)%r)) then
print*, i, 'not deallocated'
end if
end do
end subroutine
end module
program test
use mod1
type(t) :: z(6)
integer :: i
do i = 1, 6
Allocate(z(i)%r(i))
end do
call do_smth(z(::2))
end
```
Similar change was done in D142527
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D144553
Derived type default initialization was not taking the step into
consideration.
```
module dt_init
type p1
integer :: a
end type
type, extends(p1) :: p2
integer :: b = 10
end type
contains
subroutine init_dt(z)
class(p1), intent(out) :: z(:)
select type(z)
type is (p2)
print*,z
end select
end subroutine
end module
program test
use dt_init
type(p2) :: t(6) = [ p2(1,2),p2(3,4),p2(5,6),p2(7,8),p2(9,10),p2(11,12) ]
print*,t
call init_dt(t(::2))
print*,t
end program
```
Without the fix, the three first elements are initialized
```
1 2 3 4 5 6 7 8 9 10 11 12
1 10 5 10 9 10
1 10 3 10 5 10 7 8 9 10 11 12
```
Where it should be element number 1,3,5
```
1 2 3 4 5 6 7 8 9 10 11 12
1 10 5 10 9 10
1 10 3 4 5 10 7 8 9 10 11 12
```
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D142527
The code that computed the extent of a dimension of a
non-allocatable/non-automatic component array during
finalization had a reversed subtraction; fix, and
use variables to make the code a little more readable.
Differential Revision: https://reviews.llvm.org/D121163
Add explicit documentation for a couple of cases where the Fortran
standard has been observed to be ambiguous or nonspecific and we've
had to choose the behavior of the implementation from some possible
alternatives (and may be distinct from other implementations).
Differential Revision: https://reviews.llvm.org/D111446
Move the closure of the subset of flang/runtime/*.h header files that
are referenced by source files outside flang/runtime (apart from unit tests)
into a new directory (flang/include/flang/Runtime) so that relative
include paths into ../runtime need not be used.
flang/runtime/pgmath.h.inc is moved to flang/include/flang/Evaluate;
it's not used by the runtime.
Differential Revision: https://reviews.llvm.org/D109107
Define an API for, and implement, runtime support for arbitrary
assignment of one descriptor's data to another, with full support for
(re)allocation of allocatables with finalization when necessary,
user-defined derived type assignment TBP calls, and intrinsic (default)
componentwise assignment of derived type instances with allocation of
automatic components. Also clean up API and implementation of
finalization/destruction using knowledge gained while studying
edge cases for assignment in the 2018 standard.
The look-up procedure for special procedure bindings in derived
types has been optimized from O(N) to O(1) since it will probably
matter more. This required some analysis in runtime derived type
description table construction in semantics and some changes to the
table schemata.
Executable Fortran tests have been developed; they'll be added
to the test base once they can be lowered and run by f18.
Differential Revision: https://reviews.llvm.org/D107678
Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final subroutines. Perform these operations automatically for
ALLOCATE()/DEALLOCATE() APIs for allocatables, automatics, and
pointers. Add APIs for use in lowering to perform these operations
for non-allocatable/automatic non-pointer variables.
Data pointer component initialization supports arbitrary constant
designators, a F'2008 feature, which may be a first for Fortran
implementations.
Differential Revision: https://reviews.llvm.org/D106297
With derived type description tables now available to the
runtime library, it is possible to implement the concept
of "child" I/O statements in the runtime and use them to
convert instances of derived type I/O data transfers into
calls to user-defined subroutines when they have been specified
for a type. (See Fortran 2018, subclauses 12.6.4.8 & 13.7.6).
- Support formatted, list-directed, and NAMELIST
transfers to internal parent units; support these, and unformatted
transfers, for external parent units.
- Support nested child defined derived type I/O.
- Parse DT'foo'(v-list) FORMAT data edit descriptors and passes
their strings &/or v-list values as arguments to the defined
formatted I/O routines.
- Fix problems with this feature encountered in semantics and
FORMAT valiation during development and end-to-end testing.
- Convert typeInfo::SpecialBinding from a struct to a class
after adding a member function.
Differential Revision: https://reviews.llvm.org/D104930
This is *not* user-defined derived type I/O, but rather Fortran's
built-in capabilities for using derived type data in I/O lists
and NAMELIST groups.
This feature depends on having the derived type description tables
that are created by Semantics available, passed through compilation
as initialized static objects to which pointers can be targeted
in the descriptors of I/O list items and NAMELIST groups.
NAMELIST processing now handles component references on input
(e.g., "&GROUP x%component = 123 /").
The C++ perspectives of the derived type information records
were transformed into proper classes when it was necessary to add
member functions to them.
The code in Semantics that generates derived type information
was changed to emit derived type components in component order,
not alphabetic order.
Differential Revision: https://reviews.llvm.org/D104485
Define Fortran derived types that describe the characteristics
of derived types, and instantiations of parameterized derived
types, that are of relevance to the runtime language support
library. Define a suite of corresponding C++ structure types
for the runtime library to use to interpret instances of the
descriptions.
Create instances of these description types in Semantics as
static initializers for compiler-created objects in the scopes
that define or instantiate user derived types.
Delete obsolete code from earlier attempts to package runtime
type information.
Differential Revision: https://reviews.llvm.org/D92802
