[flang-commits] [flang] [flang][Lower] Implement lowering for new expression kind used in explicit-shape-bounds-spec (PR #215403)

[via flang-commits]

ivanrodriguez3753 wrote:

Sorry for the delay, I ended up making a pretty major change. I was struggling a lot with side-stepping some of the issues with using __builtin_rank1_bound_element as a rendering of a ROBE in a modfile. Furthermore, I discovered this pre-existing bug that made me feel like fixing those clashes were beyond the scope of this PR. Observe the following rejected case, using __builtin_int:
```
> cat upstream_int_type.f90 
! NO rank-1 feature used. Just a user type named __builtin_int plus an ordinary
! int(n,4) kind conversion in a scalar explicit-shape bound, which upstream
! renders as __builtin_int(...) in the modfile.
module uint
  type :: __builtin_int
    integer :: c
  end type
contains
  subroutine s(n, a)
    integer(8), intent(in) :: n
    real :: a(int(n,4))
    a(1) = 0.0
  end subroutine
end module
> cat upstream_int_cons.f90 
program p
 use uint
end program
> flang upstream_int_type.f90 upstream_int_cons.f90 
error: Semantic errors in upstream_int_cons.f90
uint.mod:9:16: error: Must have INTEGER type, but is __BUILTIN_INT
  real(4)::a(1_8:__builtin_int(__builtin_int(n,kind=4),kind=8))
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
uint.mod:9:30: error: Value in structure constructor of type '__builtin_int' is incompatible with component 'c' of type 'INTEGER(4)'
  real(4)::a(1_8:__builtin_int(__builtin_int(n,kind=4),kind=8))
                               ^^^^^^^^^^^^^^^^^^^^^^^
uint.mod:4:13: Declaration of 'c'
  integer(4)::c
              ^
uint.mod:9:46: error: Keyword 'kind=' does not name a component of derived type '__builtin_int'
  real(4)::a(1_8:__builtin_int(__builtin_int(n,kind=4),kind=8))
                                               ^^^^
uint.mod:9:54: error: Keyword 'kind=' does not name a component of derived type '__builtin_int'
  real(4)::a(1_8:__builtin_int(__builtin_int(n,kind=4),kind=8))
                                                       ^^^^
```
I was under the impression that Fortran names couldn't start with _, and `Extensions.md` only seems to document `$` and `@` as non-standard accepted characters, but it seems `_` is valid too (in `flang/include/flang/Parser/characters.h`):
```
inline constexpr bool IsLegalIdentifierStart(char ch) {
  return IsLetter(ch) || ch == '_' || ch == '@' || ch == '$';
}
```
In short, I noticed that my previous `ROBE`/`__builtin_rank1_bound_element` was very similar to ubound/lbound intrinsics, so we can just serialize in terms of those. There are a few corner cases that don't allow us to do that, in which case we fallback to emitting the entire intrinsic as a runtime inquiry. I think this is a small price to pay, given barely any cases DON'T fold to the usual syntax (indexed arrays). This involved some special casing and changes to Bound copying to ensure provenance carries over. We require provenance when we want to fold an array bound that itself was an inquiry into an array that used ROBEs in its declaration. See tests for more details, and which cases are/aren't foldable. That is, which cases fallback to a runtime inquiry. 


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