A recent patch introduced an error in an aligned byte size calculation
that causes an extra word to be allocated when the original byte size is
already aligned (including the case of zero). Fix.
Extend the runtime validation of deallocated pointers so that it also
works when pointers are allocated &/or deallocated outside Fortran.
Previously, bogus runtime errors would be reported for pointers
allocated via CFI_allocate() and deallocated in Fortran, and
CFI_deallocate() did not check that it was deallocating a whole
contiguous pointer that was allocated as such.
This commit adds required files into the offload build closure,
which means adding RT_API_ATTRS and other markers.
The implementation does not work for CUDA yet, because of
std::variant,swap,reverse usage. These issues will be resolved
separately (e.g. by using libcudacxx header files).
Avoid referencing executionEnvironment in the device code, since
environment.cpp is not part of the CUDA build yet.
This is a temporary fix before #85182 is merged.
…check
Add an environment variable by which a user can disable the pointer
validation check in DEALLOCATE statement handling. This is not safe, but
it can help make a code work that allocates a pointer with an extended
derived type, associates its target with a pointer to one of its
ancestor types, and then deallocates that pointer.
The standard requires a compiler to diagnose an incorrect use of a
pointer in a DEALLOCATE statement. The pointer must be associated with
an entire object that was allocated as a pointer (not allocatable) by an
ALLOCATE statement.
Implement by appending a validation footer to pointer allocations. This
is an extra allocated word that encodes the base address of the
allocation. If it is not found after the data payload when the pointer
is deallocated, signal an error. There is a chance of a false positive
result, but that should be vanishingly unlikely.
This change requires all pointer allocations (not allocatables) to take
place in the runtime in PointerAllocate(), which might be slower in
cases that could otherwise be handled with a native memory allocation
operation. I believe that memory allocation of pointers is less common
than with allocatables, which are not affected. If this turns out to
become a performance problem, we can inline the creation and
initialization of the footer word.
Fixes https://github.com/llvm/llvm-project/issues/78391.
Ensure that the f18Addendum flag is preserved in AllocatableApplyMold(),
that raw().type is reinitialized in AllocatableDeallocatePolymorphic(),
and that the implementations of SameTypeAs() and ExtendsTypeOf() handle
unallocated unlimited polymorphic arguments correctly.
Source allocation with a zero sized array is legal, and the resulting
allocatable/pointer should be allocated/associated.
The current code skipped the actual allocation, leading the allocatable
or pointer to look unallocated/disassociated.
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
Only apply the change made in D145604 for derived-type.
zero-sized character for example are supposed to give a false result
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145675
When a derived-type as no component, its elem_len will be set to
zero when emboxed. Update the function to let empty derived-type
pointer/target succeed the test.
Example extracted from gfortran test pointer_init_8
```
module m
type :: c
end type c
type, extends(c) :: d
end type d
type(c), target :: x
end module
use m
class(c), pointer :: px => x
if (.not. associated(px, x)) STOP 1
end
```
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D145604
The bounds descriptor passed to the function is an array of [2, newRank]
size. Update the code so the rank is retrieved from the second dimension
and not the rank of the descriptor directly as it will be 2 in any case.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D144949
When calling PointerAssociateRemapping the dynamic type information
from the target needs to be carried over to the pointer if any.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D143717
Detect and handle LHS/RHS aliasing when effecting intrinsic
assignments via the Assign() runtime function.
Also: don't apply special handling for allocatable LHS when calling
a user-defined type-bound ASSIGNMENT(=) generic procedure for a
polymorphic type, and refactor some code into utility functions to
make Assign() more comprehensible.
Differential Revision: https://reviews.llvm.org/D144026
In some remapping case the rank of the pointer is different
from the target one.
```
program remap
type :: p
integer :: a
end type t
type(p), target :: ta(10) = [ (t(i),i=1,10) ]
class(t), pointer :: p(:,:)
p(1:2,1:5) => ta
end
```
This patch updates the rank and the byte stride to fix such case.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D143566
Derived type from the MOLD was not carried over
to the newly allocated pointer or allocatable.
This may lead to wrong dynamic type when the pointer or allocatable
is polymorphic as shown in the example below:
```
type :: p1
integer :: a
end type
type, extends(p1) :: p2
integer :: b
end type
class(p1), pointer :: p(:)
allocate(p(5), MOLD=p2(1,2))
```
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D143525
The rank from the allocate object might be different from the rank
from the mold expression. Use the rank from the allocate object
when applying to mold so the bounds can be set correctly.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D143078
As Fortran 2018 9.7.1.2(7), the value of each element of allocate object
becomes the value of source when the allocate object is array and the
source is scalar.
Fix#60090.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142112
`PointerAssociateRemapping` expect a descriptor holding
a newRank x 2 array of int64. The previous lowering was wrong.
Adapt the lowering to fit the expectation of the runtime.
Use the `bounds` to get the rank.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142487
When an unlimited polymorphic descriptor is establish for an intrinsic
type spec, the `PointerNullifyIntrinsic` or `AllocatableInitIntrinsic` runtime
function is called. These functions do not initialize an addendum with a derivedType.
When the deallocation on this descriptor is performed, the runtime should not
crash if the addendum is not present. This patch updates `PointerDeallocatePolymorphic`
and `AllocatableDeallocatePolymorphic` for this use case.
Depends on D141996
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142010
Support allocate statement with source in runtime version. The source
expression is evaluated only once for each allocate statement. When the
source expression has shape-spec, uses it for bounds. Otherwise, get
the bounds from the source expression. Get the length if the source
expression has deferred length parameter.
Reviewed By: clementval, jeanPerier
Differential Revision: https://reviews.llvm.org/D137812
As mentioned in section 7.3.2.3 note 7, The dynamic type of an unallocated
allocatable object or a disassociated pointer is the same as its declared type.
This patch adds two function to the runtime:
- `PointerDeallocatePolymorphic`
- `AllocatableDeallocatePolymorphic`
These two functions take a DerivedTypeDesc pointer of the declared type.
The lowering is updated accordingly to call these functions for polymorphic
and unlimited polyrmophic entities. For unlimited polymorphic entities, the
dynamic type is set to nullptr when the entity is on an unallocated or
disassociated state.
Reviewed By: PeteSteinfeld, klausler
Differential Revision: https://reviews.llvm.org/D141519
The code is iterating on the rank of the pointer to set the bounds.
If the rank is retrieved after the `pointer = target` it does not
reflect the actual rank of the pointer.
This could happen in code like the following:
```
type t1
integer :: a
end type
type(t), pointer :: p(:)
class(t), pointer :: q(:,:)
q(0:1,-2:2) => p(10:1:-1)
```
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D139327
ASSOCIATED() must be false for zero-sized arrays, and the
strides on a dimension are irrelevant when the extent is unitary.
Differential Revision: https://reviews.llvm.org/D127793
PointerDeallocate was silently doing nothing because it relied on
Destroy that doe not do anything for Pointers. Add an option to Destroy
in order to destroy pointers.
Add a unit test for PointerDeallocate.
Differential Revision: https://reviews.llvm.org/D122492
LBOUND must return 1 for an empty dimension, no matter what
explicit expression might appear in a declaration or arrive in
a descriptor.
Differential Revision: https://reviews.llvm.org/D121488
The TARGET argument of ASSOCIATED may be dynamically optional, in which
case ASSOCIATED(POINTER, TARGET) is equal to ASSOCIATED(TARGET).
Make the runtime argument a pointer so that it can detect and handle
arguments that are dynamically optional.
Also fix the runtime to check if TARGET base address is not null and if
its element size is not null to match the requirement of ASSOCIATED
regarding TARGET:
- if TARGET is an object: true iff [..] TARGET is not a zerosized storage sequence
- if TARGET is a POINTER: true iff [..] POINTER and TARGET are associated
Not that ASSOCIATED will also returns false if TARGET is an unallocated allocatable.
This is not described in the standard, but is a unanimous behaviour of
existing compilers.
Differential Revision: https://reviews.llvm.org/D120835
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
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
