[all-commits] [llvm/llvm-project] de8939: [flang] Reset lbounds for allocatable function res...

[Slava Zakharin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: de8939ffca277670613904872e55a9a4d9f19b94
      https://github.com/llvm/llvm-project/commit/de8939ffca277670613904872e55a9a4d9f19b94
  Author: Slava Zakharin <szakharin at nvidia.com>
  Date:   2023-09-05 (Tue, 05 Sep 2023)

  Changed paths:
    M flang/lib/Lower/Bridge.cpp
    A flang/test/Lower/HLFIR/allocatable-return.f90
    A flang/test/Lower/allocatable-return.f90

  Log Message:
  -----------
  [flang] Reset lbounds for allocatable function results. (#65286)

With HLFIR the lbounds for the ALLOCATABLE result are taken from the
mutable box created for the result, so the non-default lbounds might be
propagated further causing incorrect result, e.g.:
```
program p
  real, allocatable :: p5(:)
  allocate(p5, source=real_init())
  print *, lbound(p5, 1) ! must print 1, but prints 7
contains
  function real_init()
    real, allocatable :: real_init(:)
    allocate(real_init(7:8))
  end function real_init
end program p
```

With FIR lowering the box passed for `source` has explicit lower bound 1
at the call site, but the runtime box initialized by `real_init` call
still has lower bound 7. I am not sure if the runtime box initialized by
`real_init` will ever be accessed in a debugger via Fortran variable
names, but I think that having the right runtime bounds that can be
accessible via examining registers/stack might be good in general. So I
decided to update the runtime bounds at the point of return.

This change fixes the test above for HLFIR.

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D156187