[flang-commits] [flang] [llvm] [Flang] Adding lowering for the allocation and deallocation of coarrays (PR #182110)

[Dan Bonachea via flang-commits]

================
@@ -701,6 +730,14 @@ static void instantiateGlobal(Fortran::lower::AbstractConverter &converter,
   mlir::Value cast = builder.createConvert(loc, varAddrType, addrOf);
   Fortran::lower::StatementContext stmtCtx;
   mapSymbolAttributes(converter, var, symMap, stmtCtx, cast);
+  // Local coarray must have the SAVE or ALLOCATABLE attribute and are
+  // never explicitly deallaocated or finalized (see 7.5.6.4).
+  // Otherwize, a coarray is global we will add an implicit deallocation
+  // for nonallocatable and nonpointer at the end of the scope.
+  if (Fortran::evaluate::IsCoarray(sym) &&
+      !Fortran::semantics::IsAllocatable(sym) &&
+      !Fortran::semantics::IsPointer(sym))
+    genCleanupDeallocateCoarray(converter, var, symMap);
----------------
bonachea wrote:

Sounds good. 

Note that a local ALLOCATABLE coarray should only be automatically deallocated at scope exit if it meets ALL the following criteria: (see F23 9.7.3.2)
1. It is not `SAVE`
2. It is not a dummy argument
3. It is currently allocated (probably requires a runtime check in general)
4. It is not a function result or subobject of a function result (for RETURN or END statement)

On a related topic, there are also other places where compiler-driven automatic deallocation of coarrays must occur. For example:

1. when calling a procedure with an actual argument corresponding to an INTENT(OUT) dummy argument, where the actual argument is an allocated ALLOCATABLE (or has one as a subobject) (see F23 9.7.3.2). 
2. when calling `MOVE_ALLOC` where the TO argument is an allocated ALLOCATABLE (See F23 16.9.147).
3. at the end of the innermost executable construct containing a function reference that returned an allocated ALLOCATABLE function result

There may be others I'm not recalling at the moment. These cases will all require code gen to insert a call to `prif_deallocate_coarray` (and thus probably `mif_DeallocCoarrayOp`), but that might be handled in a different part of the compiler/runtime (which already enforces these rules for non-coarray ALLOCATABLE variables).

https://github.com/llvm/llvm-project/pull/182110