[flang-commits] [flang] [Flang][OpenMP] Align map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types (PR #97855)

[via flang-commits]

================
@@ -970,25 +970,21 @@ bool ClauseProcessor::processMap(
                   object.ref(), clauseLocation, asFortran, bounds,
                   treatIndexAsSection);
 
-          auto origSymbol = converter.getSymbolAddress(*object.sym());
-          mlir::Value symAddr = info.addr;
-          if (origSymbol && fir::isTypeWithDescriptor(origSymbol.getType()))
-            symAddr = origSymbol;
-
           // Explicit map captures are captured ByRef by default,
           // optimisation passes may alter this to ByCopy or other capture
           // types to optimise
+          mlir::Value baseOp = info.rawInput;
----------------
agozillon wrote:

```
subroutine omp_target_implicit_bounds(n, m)
    integer(8) :: n,m
    integer :: a(n:m)
   !$omp target
       a(4) = 22
       a(15) = 2222
   !$omp end target
    print *, a
! Results in:  22 0 0 0 0 0 0 0 0 0 0 2222
end subroutine omp_target_implicit_bounds

subroutine omp_target_passed_in_implicit_bounds(n, m, a)
    integer(8) :: n,m
    integer :: a(n:m)
   !$omp target
       a(4) = 22
       a(15) = 2222
   !$omp end target
end subroutine omp_target_passed_in_implicit_bounds

program test
    integer(8) :: n,m
    integer :: array(20)
    n = 4
    m = 15
    call omp_target_implicit_bounds(n,m)
    call omp_target_passed_in_implicit_bounds(n, m, array)
    print *, array
    ! Results in: 22 0 0 0 0 0 0 0 0 0 0 2222 0 0 0 0 0 0 0 0
end program
```

Thank you very much @jeanPerier, I took your test and expanded it a bit into a full program, it seems to function as I would expect (although, I am far from a Fortran expert) providing the same results when there is a target region and when there's not.

>From IR introspection, it does appear we create a hlfir.declare inside of the target region, and specify a shapeshift (lower bound and extent) calculated from mapped in bounds information.

So, it seems if the above assessment is correct, using the raw input for the moment is fine. At least from a correctness perspective, I am not sure which would come with a higher performance tax (if either).

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