# Assumed-Rank Objects An assumed-rank dummy data object is a dummy argument that takes its rank from its effective argument. It is a dummy argument, or the associated entity of a SELECT RANK in the `RANK DEFAULT` block. Its rank is not known at compile time. The rank can be anything from 0 (scalar) to the maximum allowed rank in Fortran (currently 15 according to Fortran 2018 standard section 5.4.6 point 1). This document summarizes the contexts where assumed-rank objects can appear, and then describes how they are implemented and lowered to HLFIR and FIR. All section references are made to the Fortran 2018 standard. ## Fortran Standard References Here is a list of sections and constraints from the Fortran standard involving assumed-ranks. - 7.3.2.2 TYPE - C711 - 7.5.6.1 FINAL statement - C789 - 8.5.7 CONTIGUOUS attribute - C830 - 8.5.8 DIMENSION attribute - 8.5.8.7 Assumed-rank entity - C837 - C838 - C839 - 11.1.10 SELECT RANK - 15.5.2.13 Restrictions on entities associated with dummy arguments - 1 (3) (b) and (c) - 1 (4) (b) and (c) - 15.5.2.4 Ordinary dummy variables - point 17 - 18 Interoperability with C - 18.3.6 point 2 (5) ### Summary of the constraints: Assumed-rank can: - be pointers, allocatables (or have neither of those atttributes). - be monomorphic or polymorphic (both `TYPE(*)` and `CLASS(*)`) - have all the attributes, except VALUE and CODIMENSION (C837). Notably, they can have the CONTIGUOUS or OPTIONAL attributes (C830). - appear as an actual argument of an assumed-rank dummy (C838) - appear as the selector of SELECT RANK (C838) - appear as the argument of C_LOC and C_SIZEOF from ISO_C_BINDING (C838) - appear as the first argument of inquiry intrinsic functions (C838). These inquiry functions listed in table 16.1 are detailed in the "Assumed-rank features" section below. - appear in BIND(C) and non BIND(C interface (18.1 point 3) - be finalized on entry as INTENT(OUT) under some conditions that prevents the assumed-rank to be associated with an assumed-size. - be associated with any kind of scalars and arrays, including assumed-size. Assumed-rank cannot: - be coarrays (C837) - have the VALUE attribute (C837) - be something that is not a named variable (they cannot be the result of a function or a component reference) - appear in a designator other than the case listed above (C838). Notably, they cannot be directly addressed, they cannot be used in elemental operations or transformational intrinsics, they cannot be used in IO, they cannot be assigned to.... - be finalized on entry as INTENT(OUT) if it could be associated with an assumed-size (C839). - be used in a reference to a procedure without an explicit interface (15.4.2.2. point 3 (c)). With regard to aliasing, assumed-rank dummy objects follow the same rules as for assumed shapes, with the addition of 15.5.2.13 (c) which adds a rule when the actual is a scalar (adding that TARGET assumed-rank may alias if the actual argument is a scalar even if they have the CONTIGUOUS attribute, while it is OK to assume that CONTIGUOUS TARGET assumed shape do not alias with other dummies). --- ## Assumed-Rank Representations in Flang ### Representation in Semantics In semantics (there is no concept of assumed-rank expression needed in `evaluate::Expr`). Such symbols have either `semantics::ObjectEntityDetails` ( dummy data objects) with a `semantics::ArraySpec` that encodes the "assumed-rank-shape" (can be tested with IsAssumedRank()), or they have `semantics::AssocEntityDetails` (associated entity in the RANK DEFAULT case). Inside a select rank, a `semantics::Symbol` is created for the associated entity with `semantics::AssocEntityDetails` that points to the the selector and holds the rank outside of the RANK DEFAULT case. Assumed-rank dummies are also represented in the `evaluate::characteristics::TypeAndShape` (with the AssumedRank attribute) to represent assumed-rank in procedure characteristics. ### Runtime Representation of Assumed-Ranks Assumed-ranks are implemented as CFI_cdesc_t (18.5.3) with the addition of an f18 specific addendum when required for the type. This is the usual f18 descriptor, and no changes is required to represent assumed-ranks in this data structure. In fact, there is no difference between the runtime descriptor created for an assumed shape and the runtime descriptor created when the corresponding entity is passed as an assumed-rank. This means that any descriptor can be passed to an assumed-rank dummy (with care to ensure that the POINTER/ALLOCATABLE attribute match the dummy argument attributes as usual). Notably, any runtime interface that takes descriptor arguments of any ranks already work with assumed-rank entities without any changes or special cases. This also implies that the runtime cannot tell that an entity is an assumed-rank based on its descriptor, but there seems to be not need for this so far ("rank based" dispatching for user defined assignments and IO is not possible with assumed-ranks, and finalization is possible, but there is no need for the runtime to distinguish between finalization of an assumed-rank and finalization of other entities: only the runtime rank matters). The only difference and difficulty is that descriptor storage size of assumed-rank cannot be precisely known at compile time, and this impacts the way descriptor copies are generated in inline code. The size can still be maximized using the maximum rank, which the runtime code already does when creating temporary descriptor in many cases. Inline code also needs care if it needs to access the descriptor addendum (like the type descriptor), since its offset will not be a compile time constant as usual. Note that an alternative to maximizing the allocation of assumed-rank temporary descriptor could be to use automatic allocation based on the rank of the input descriptor, but this would make stack allocation analysis more complex (tools will likely not have the Fortran knowledge that this allocation size is bounded for instance) while the stack "over" allocation is likely reasonable (24 bytes per dimension). Hence the selection of the simple approach using static size allocation to the maximum rank. ### Representation in FIR and HLFIR SSA values for assumed-rank entities have an MLIR type containing a `!fir.array<*xT>` sequence type wrapped in a `!fir.box` or `!fir.class` type (additionally wrapped in a `!fir.ref` type for pointers and allocatables). Examples: `INTEGER :: x(..)` -> `!fir.box>` `CLASS(*) :: x(..)` -> `!fir.class>` `TYPE(*) :: x(..)` -> `!fir.box>` `REAL, ALLOCATABLE :: x(..)` -> `!fir.ref>>>` `TYPE(t), POINTER :: x(..)` -> `!fir.ref>>>>` All these FIR types are implemented as the address of a CFI_cdesc_t in code generation. There is no need to allow assumed-rank "expression" in HLFIR (hlfir.expr) since assumed-rank cannot appear in expressions (except as the actual argument to an assumed-rank dummy). Assumed-rank are variables. Also, since they cannot have the VALUE attribute, there is no need to use the hlfir.as_expr + hlfir.associate idiom to make copies for them. FIR/HLFIR operation where assumed-rank may appear: - as `hlfir.declare` and `fir.declare` operand and result. - as `fir.convert` operand and/or result. - as `fir.load` operand and result (POINTER and ALLOCATABLE dereference). - as a block argument (dummy argument). - as `fir.rebox_assumed_rank` operand/result (new operation to change some fields of assumed-rank descriptors). - as `fir.box_rank` operand (rank inquiry). - as `fir.box_dim` operand (brutal user inquiry about the bounds of an assumed-rank in a compile time constant dimension). - as `fir.box_addr` operand (to get the base address in inlined code for C_LOC). - as `fir.box_elesize` operand (to implement LEN and STORAGE_SIZE). - as `fir.absent` result (passing absent actual to OPTIONAL assumed-rank dummy) - as `fir.is_present` operand (PRESENT inquiry) - as `hlfir.copy_in` and `hlfir.copy_out` operand and result (copy in and copy-out of assumed-rank) - as `fir.alloca` type and result (when creating an assumed-rank POINTER dummy from a non POINTER dummy). - as `fir.store` operands (same case as `fir.alloca`). FIR/HLFIR Operations that should not need to accept assumed-ranks but where it could still be relevant: - `fir.box_tdesc` and `fir.box_typecode` (polymorphic assumed-rank cannot appear in a SELECT TYPE directly without using a SELECT RANK). Given the CFI_cdesc_t structure, no change would be needed for `fir.box_typecode` to support assumed-ranks, but `fir.box_tdesc` would require change since the position of the type descriptor pointer depends on the rank. - as `fir.allocmem` / `fir.global` result (assumed-ranks are never local/global entities). - as `fir.embox` result (When creating descriptor for an explicit shape, the descriptor can be created with the entity rank, and then casted via `fir.convert`). It is not expected for any other FIR or HLFIR operations to handle assumed-rank SSA values. #### Summary of the impact in FIR One new operation is needed, `fir.rebox_assumed_rank`, the rational being that fir.rebox codegen is already quite complex and not all the aspects of fir.rebox matters for assumed-ranks (only simple field changes are required with assumed-ranks). Also, this operation will be allowed to take an operand in memory to avoid expensive fir.load of pointer/allocatable inputs. The operation will also allow creating rank-one assumed-size descriptor from an input assumed-rank descriptor to cover the SELECT RANK `RANK(*)` case. It is proposed that the FIR descriptor inquiry operation (fir.box_addr, fir.box_rank, fir.box_dim, fir.box_elesize at least) be allowed to take fir.ref arguments (allocatable and pointer descriptors) directly instead of generating a fir.load first. A conditional "read" effect will be added in such case. Again, the purpose is to avoid generating descriptor copies for the sole purpose of satisfying the SSA IR constraints. This change will likely benefit the non assumed-rank case too (even though LLVM is quite good at removing pointless descriptor copies in these cases). It will be ensured that all the operation listed above accept assumed-rank operands (both the verifiers and coedgen). The codegen of `fir.load`, `fir.alloca`, `fir.store`, `hlfir.copy_in` and `hlfir.copy_out` will need special handling for assumed-ranks. ### Representation in LLVM IR Assumed-rank descriptor types are lowered to the LLVM type of a CFI_cdesc_t descriptor with no dimension array field and no addendum. That way, any inline code attempt to directly access dimensions and addendum with constant offset will be invalid for more safety, but it will still be easy to generate LLVM GEP to address the first descriptor fields in LLVM (to get the base address, rank, type code and attributes). `!fir.box>` -> `!llvm.struct<(ptr, i64, i32, i8, i8, i8, i8>` ## Assumed-rank Features This section list the different Fortran features where assumed-rank objects are involved and describes the related implementation design. ### Assumed-rank in procedure references Assumed-rank arguments are implemented as being the address of a CFI_cdesc_t. When passing an actual argument to an assumed-rank dummy, the following points need special attention and are further described below: - Copy-in/copy-out when required - Creation of forwarding of the assumed-rank dummy descriptor (including when the actual is an assumed-size). - Finalization, deallocation, and initialization of INTENT(OUT) assumed-rank dummy. OPTIONAL assumed-ranks are implemented like other non assumed-rank OPTIONAL objects passed by descriptor: an absent assumed-rank is represented by a null pointer to a CFI_cdesc_t. The passing interface for assumed-rank described above and below is compliant by default with the BIND(C) case, except for the assumed-rank dummy descriptor lower bounds, which are only set to zeros in BIND(C) interface because it implies in most of the cases to create a new descriptor. VALUE is forbidden for assumed-rank dummies, so there is nothing to be done for it (although since copy-in/copy-out is possible, the compiler must anyway deal with creating assumed-rank copies, so it would likely not be an issue to relax this constraint). #### Copy-in and Copy out Copy-in and copy-out is required when passing an actual that is not contiguous to a non POINTER CONTIGUOUS assumed-rank. When the actual argument is ranked, the copy-in/copy-out can be performed on the ranked actual argument where the dynamic type has been aligned with the dummy type if needed (passing CLASS(T) to TYPE(T)) as illustrated below. ```Fortran module m type t  integer :: i end type contains subroutine foo(x)  class(t) :: x(:)  interface   subroutine bar(x)     import :: t     type(t), contiguous :: x(..)   end subroutine  end interface  ! copy-in and copy-out is required aroud bar  call bar(x) end end module ``` When the actual is also an assumed-rank special the same copy-in/copy-out need may arise, and the `hlfir.copy_in` and `hlfir.copy_out` are also used to cover this case. The `hlfir.copy_in`operation is implemented using the `IsContiguous` runtime (can be used as-is) and the `AssignTemporary` temporary runtime. The difference with the ranked case is that more care is needed to create the output descriptor passed to `AssignTemporary`: it must be allocated to the maximum rank with the same type as the input descriptor and only the descriptor fields prior to the array dimensions will be initialized to those of an unallocated descriptor prior to the runtime call (`AssignTemporary` copies the addendum if needed). ```Fortran subroutine foo2(x)  class(t) :: x(..)  interface   subroutine bar(x)     import :: t     type(t), contiguous :: x(..)   end subroutine  end interface  ! copy-in and copy-out is required aroud bar  call bar(x) end ``` #### Creating the descriptor for assumed-rank dummies There are four cases to distinguish: 1. Actual does not have a descriptor (and is therefore ranked) 2. Actual has a descriptor that can be forwarded for the dummy 3. Actual has a ranked descriptor that cannot be forwarded for the dummy 4. Actual has an assumed-rank descriptor that cannot be forwarded for the dummy For the first case, a descriptor will be created for the dummy with `fir.embox` has if it has the rank of the actual argument. This is the same logic as when dealing with assumed shape or INTENT(IN) POINTER dummy arguments, except that an extra cast to the assumed-rank descriptor type is added (no-op at runtime). Care must be taken to set the final dimension extent to -1 in the descriptor created for an assumed-size actual argument. Note that the descriptor created for an assumed-size still has the rank of the assumed-size, a rank-one descriptor will be created for it if needed in a RANK(*) block (nothing says that an assumed-size should be passed as a rank-one array in 15.5.2.4 point 17). For the second case, a cast is added to assumed-rank descriptor type if it is not one already and the descriptor is forwarded. For the third case, a new ranked descriptor with the dummy attribute/lower bounds is created from the actual argument descriptor with `fir.rebox` as it is done when passing to an assume shape dummy, and a cast to the assumed-rank descriptor is added . The last case is the same as the third one, except the that the descriptor manipulation is more complex since the storage size of the descriptor is unknown. `fir.rebox` codegen is already quite complex since it deals with creating descriptor for descriptor based array sections and pointer remapping. Both of those are meaningless in this case where the output descriptor is the same as the input one, except for the lower bounds, attribute, and derived type pointer field that may need to be changed to match the values describing the dummy. A simpler `fir.rebox_assumed_rank` operation is added for this use case. Notably, this operation can take fir.ref inputs to avoid creating an expensive and useless fir.load of POINTER/ALLOCATABLE descriptors. Fortran requires the compiler to fall in the 3rd and 4th case and create descriptor temporary for the dummy a lot more than one would think and hope. An annex section below discusses cases that force the compiler to create a new descriptor for the dummy even if the actual already has a descriptor. These are the same situations than with non assumed-rank arguments, but when passing assumed-rank to assumed-ranks, the cost of this extra copy is higher. #### Intent(out) assumed-rank finalization, deallocation, initialization The standard prevents INTENT(OUT) assumed-rank requiring finalization to be associated with assumed-size arrays (C839) because there would be no way to finalize such entities. But INTENT(OUT) finalization is still possible if the actual is not an assumed-size and not a nonpointer nonallocatable assumed-rank. Flang therefore needs to implement finalization, deallocation and initialization of INTENT(OUT) as usual. Non pointer non allocatable INTENT(OUT) finalization is done via a call to `Destroy` runtime API that takes a descriptor and can be directly used with an assumed-rank descriptor with no change. The initialization is done via a call to the `Initialize` runtime API that takes a descriptor and can also directly be used with an assumed descriptor. Conditional deallocation of INTENT(OUT) allocatable is done via an inline allocation status check and either an inline deallocate for intrinsic types, or a runtime call to `Deallocate` for the other cases. For assumed-ranks, the runtime call is always used regardless of the type to avoid inline descriptor manipulations. `Deallocate` runtime API also works with assumed-rank descriptors with no changes (like any runtime API taking descriptors of any rank). ```Fortran subroutine foo(x)  class(*), allocatable :: x(..)  interface   subroutine bar(x)     class(*), intent(out) :: x(..)   end subroutine  end interface  ! x may require finalization and initialization on bar entry.  call bar(x) end subroutine bar(x)   class(*), intent(out) :: x(..) end subroutine ``` ### Select Rank Select rank is implemented with a rank inquiry (and last extent for `RANK(*)`), followed by a jump in the related block where the selector descriptor is cast to a descriptor with the associated entity rank for the current block for the `RANK(cst)` cases. In the `RANK DEFAULT`, the input descriptor is kept with no cast, and in the RANK(*), a rank-one descriptor is created with the same dynamic type as the input. These new descriptor values are mapped to the associated entity symbol and lowering precede as usual. This is very similar to how Select Type is implemented. The `RANK(*)` is a bit odd, it detects assumed-ranks associated with an assumed-size arrays regardless of the rank, and takes precedence over any rank based matching. Note that `-1` is a magic extent number that encodes that a descriptor describes an entity that is an assumed-size (user specified extents of explicit shape arrays are always normalized to zero when negative, so `-1` is a safe value to identify a descriptor created for an assumed-size). It is actually well specified for the BIND(C) (18.5.2 point 1.) and is always used as such in flang descriptors. The implementation of SELECT RANK is done as follow: - Read the rank `r` in the descriptor - If there is a `RANK(*)`, read the extent in dimension `r`. If it is `-1`, jump to the `RANK(*)` block. Otherwise, continue to the steps below. - For each `RANK(constant)` case, compare `constant` to `r`. Stop at first match and jump to related block. The order of the comparisons does not matter (there cannot be more than one match). - Jump to `RANK DEFAULT` block is any. Otherwise jump to the end of the construct. The blocks for each cases jumps at the end of the construct at the end. As opposed to SELECT TYPE, no clean-up should be needed at the construct level since the select-rank selector is a named entity and cannot be a temporary with a lifetime of the construct. Except for the `RANK(*)` case, the branching logic is implemented in FIR with a `fir.select_case` operating on the rank. Example: ```Fortran subroutine test(x) interface subroutine assumed_size(x) real :: x(*) end subroutine subroutine scalar(x) real :: x end subroutine subroutine rank_one(x) real :: x(:) end subroutine subroutine many_dim_array(x) real :: x(..) end subroutine end interface real :: x(..) select rank (y => x) rank(*) call assumed_size(y) rank(0) call scalar(y) rank(1) call rank_one(y) rank default call many_dim_array(y) end select end subroutine ``` Pseudo FIR for the example (some converts and SSA constants creation are not shown for more clarity): ``` func.func @_QPtest(%arg0: !fir.box>) { %x:2 = hlfir.declare %arg0 {uniq_name = "_QFtestEx"} : (!fir.box>) -> (!fir.box>, !fir.box>) %r = fir.box_rank %x#1 : (!fir.box>) -> i32 %last_extent = fir.call @_FortranASizeDim(%x#1, %r, %sourcename, %sourceline) %is_assumed_size = arith.cmpi eq %last_extent, %c-1: (i64, i64) -> i1 cf.cond_br %is_assumed_size, ^bb_assumed_size, ^bb_not_assumed_size ^bb_assumed_size: %r1_box = fir.rebox_assumed_rank %x#0 : (!fir.box>) -> !fir.box> %addr = fir.box_addr %addr, !fir.box> -> !fir.ref> fir.call @_QPassumed_size(%addr) (!fir.ref>) -> () cf.br ^bb_end ^bb_not_assumed_size: fir.select_case %3 : i32 [#fir.point, %c0, ^bb_scalar, #fir.point, %c1, ^bb_rank1, unit, ^bb_default] ^bb_scalar: %scalar_cast = fir.convert %x#1 : (!fir.box>) -> !fir.box %x_scalar = fir.box_addr %scalar_cast: (!fir.box) -> !fir.ref fir.call @_QPscalar(%x_scalar) (!fir.ref) -> () cf.br ^bb_end ^bb_rank1: %rank1_cast = fir.convert %x#1 : (!fir.box>) -> !fir.box> fir.call @_QPrank_one(%rank1_cast) (!fir.box>) -> () cf.br ^bb_end ^bb_default: fir.call @_QPmany_dim_array(%x#1) (!fir.box>) -> () cf.br ^bb_end ^bb_end return } ``` ### Inquiry intrinsic functions #### ALLOCATED and ASSOCIATED Implemented inline with `fir.box_addr` (reading the descriptor first address inline). Currently, FIR descriptor inquiry happens at the "descriptor value" level (require a fir.load of the POINTER or ALLOCATABLE !fir.ref>), to satisfy the SSA value semantics, the fir.load creates a copy of the underlying descriptor storage. With assume ranks, this copy will be "expensive" and harder to optimize out given the descriptor storage size is not a compile time constant. To avoid this extra cost, ALLOCATABLE and POINTER assumed-ranks will be cast to scalar descriptors before the `fir.load`. ```Fortran real, allocatable :: x(..) print *, allocated(x) ``` ``` %1 = fir.convert %x : (!fir.ref>>>) -> !fir.ref>> %2 = fir.load %x : !fir.ref>> %addr = fir.box_addr %2 : (!fir.box>) -> fir.ref # .... "addr != null" as usual ``` #### LEN and STORAGE_SIZE Implemented inline with `fir.box_elesize` with the same approach as ALLOCATED/ASSOCIATED when dealing with fir.box load for POINTERS and ALLOCATABLES. ```Fortran character(*) :: x(..) print *, len(x) ``` ``` %ele_size = fir.box_elesize %x : (!fir.box>>) -> i64 # .... divide by character KIND byte size if needed as usual ``` #### PRESENT Implemented inline with `fir.is_present` which ends-up implemented as a check that the descriptor address is not null just like with OPTIONAL assumed shapes and OPTIONAL pointers and allocatables. ```Fortran real, optional :: x(..) print *, present(x) ``` ``` %is_present = fir.is_prent %x : (!fir.box>) -> i1 ``` #### RANK Implemented inline with `fir.box_rank` which simply reads the descriptor rank field. ```Fortran real :: x(..) print *, len(x) ``` ``` %rank = fir.box_rank %x : (!fir.box>) -> i32 ``` #### SIZE Using the runtime can be queried as it is done for assumed shapes. When DIM is present and is constant, `fir.box_dim` can also be used with the option to add a runtime check that RANK <= DIM. Pointers and allocatables are dereferenced, which in FIR currently creates a descriptor copy that cannot be simplified like for the previous inquiries by inserting a cast before the fir.load (the dimension info must be correctly copied). #### LBOUND, SHAPE, and UBOUND When DIM is present an is present, the runtime can be used as it is currently with assumed shapes. When DIM is absent, the result is a rank-one array whose extent is the rank. The runtime has an entry for UBOUND that takes a descriptor and allocate the result as needed, so the same logic as for assumed shape can be used. There is no such entry for LBOUND/SHAPE currently, it would likely be best to add one rather than to jungle with inline code. Pointers and allocatables dereference is similar as with SIZE. #### EXTENDS_TYPE_OF, SAME_TYPE_AS, and IS_CONTIGUOUS Using the runtime as it is done currently with assumed shapes. Pointers and allocatables dereference is similar as with SIZE. #### C_LOC from ISO_C_BINDING Implemented with `fir.box_addr` as with other C_LOC cases for entities that have descriptors. #### C_SIZE_OF from ISO_C_BINDING Implemented as STORAGE_SIZE * SIZE. #### Floating point inquiries and NEW_LINE BIT_SIZE, DIGITS, EPSILON, HUGE, KIND, MAXEXPONENT, MINEXPONENT, NEW_LINE, PRECISION, RADIX, RANGE, TINY all accept assumed-rank, but are always constant folded by semantics based on the type and lowering does not need to deal with them. #### Coarray inquiries Assumed-rank cannot be coarrays (C837), but they can still technically appear in COSHAPE (which should obviously return zero). They cannot appear in LBOUND, LCOBOUND, UBOUND, UCOBOUND that require the argument to be a coarray. ## Annex 1 - Descriptor temporary for the dummy arguments When passing an actual argument that is descriptor to a dummy that must be passed by descriptor, one could expect that the descriptor of the actual can just be forwarded to the dummy, but this is unfortunately not possible in quite some cases. This is not specific to assumed-ranks, but since the cost of descriptor temporaries is higher for assumed-ranked, it is discussed here. Below are the reasons for which a new descriptor may be required: 1. passing a POINTER to a non POINTER 2. setting the descriptor CFI_cdesc_t `attribute` according to the dummy POINTER/ALLOCATABLE attributes (18.3.6 point 4 for the BIND(C) case). 3. setting the CFI_cdesc_t lower bounds to zero for a BIND(C) assumed shape/rank dummy (18.5.3 point 3). 4. setting the derived type pointer to the dummy dynamic type when passing a CLASS() actual to a TYPE() dummy. Justification of 1.: When passing a POINTER to a non POINTER, the target of the pointer is passed, and nothing prevents the association status of the actual argument to change during the call (e.g. if the POINTER is another argument of the call, or is a module variable, it may be re-associated in the call). These association status change of the actual should not impact the dummy, so they must not share the same descriptor. Justification of 2.: In the BIND(C) case, this is required by 18.3.6 point 4. Outside of the BIND(C) case, this should still be done because any runtime call where the dummy descriptor is forwarded may misbehave if the ALLOCATABLE/POINTER attribute is not the one of the dummy (e.g. reallocation could be triggered instead of padding/trimming characters). Justification of 3: 18.5.3 point 3. Justification of 4: If the descriptor derived type info pointer is not the one of the dummy dynamic type, many runtime call like IO and assignment will misbehave when being provided the dummy descriptor. For point 2., 3., and 4., one could be tempted to change the descriptor fields before and after the call, but this is risky since this would assume nothing will access the actual argument descriptor during the call. And even without bringing any potential asynchronous behavior of OpenMP/OpenACC/Cuda Fortran extensions, the actual argument descriptor may be passed inside a call in another arguments with "different" lower bounds POINTER or ALLOCATABLE (but could also be accessed via host of use association in general). ## Annex 2 - Assumed-Rank Objects and IGNORE_TKR It is possible to: - Set IGNORE_TKR(TK) on assumed-rank dummies (but TYPE(*) is better when possible). - Pass an assumed-rank to an IGNORE_TKR(R) dummy that is not passed by descriptor (explicit shape and assumed-size). Note that copy-in and copy-out will be performed for the dummy It is not possible to: - Set IGNORE_TKR(R) on an assumed-rank dummy. Example: ```Fortran subroutine test(assumed_rank_actual) interface subroutine assumed_size_dummy(x) !dir$ ignore_tkr(tkr) x integer :: x(*) end subroutine subroutine any_type_assumed_rank(x) !dir$ ignore_tkr(tk) x integer :: x(..) end subroutine end interface real :: assumed_rank_actual(..) call assumed_size_dummy(assumed_rank_actual) !OK call any_type_assumed_rank(assumed_rank_actual) !OK end subroutine ``` ## Annex 3 - Test Plan MPI_f08 module makes usage of assumed-rank (see https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf). As such compiling MPI_f08 modules of MPI libraries and some applications making usage of MPI_f08 will be a good test for the implementation of this feature.