[Flang] verification of lowering to FIR failed with "'hlfir.minval' op result must have the same element type as ARRAY argument"

[k-arrows]

Reproducible on Godbolt:
https://godbolt.org/z/T5MeEa7r3

Reproducer:

    character(3) :: char(3, 4)
    char = 'abc'

    associate (y=>func(char))
        associate (item => y(1:2)//'aa')
        end associate
    end associate

    contains

    function func(char)
       character(:), allocatable :: func(:)
       character(3) :: char(3, 4)

       func = minval(char//' ', dim=1)
    end function
end

If I use -flang-deprecated-no-hlfir option, the following TODO message is obtained.

error: loc("/app/example.f90":15:8): /root/llvm-project/flang/lib/Lower/ConvertExpr.cpp:3412: not yet implemented: gather rhs LEN parameters in assignment to allocatable

https://godbolt.org/z/Enj4Gcajh

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: None (k-arrows)

Reproducible on Godbolt: https://godbolt.org/z/T5MeEa7r3

Reproducer:

    character(3) :: char(3, 4)
    char = 'abc'

    associate (y=>func(char))
        associate (item => y(1:2)//'aa')
        end associate
    end associate

    contains

    function func(char)
       character(:), allocatable :: func(:)
       character(3) :: char(3, 4)

       func = minval(char//' ', dim=1)
    end function
end

If I use -flang-deprecated-no-hlfir option, the following TODO message is obtained.

error: loc("/app/example.f90":15:8): /root/llvm-project/flang/lib/Lower/ConvertExpr.cpp:3412: not yet implemented: gather rhs LEN parameters in assignment to allocatable

https://godbolt.org/z/Enj4Gcajh

[tblah]

F2018 16.9.134 4 says that the result of minval has the "same type and type parameters as ARRAY". So the op verifier is right to expect these to have the same type.

Looking at the generated HLFIR, char is a !fir.ref<!fir.array<3x4x!fir.char<1,3>>>, whereas func is fir.ref<!fir.box<!fir.heap<!fir.array<?x!fir.char<1,?>>>>>.

The check is here:

llvm-project/flang/lib/Optimizer/HLFIR/IR/HLFIROps.cpp

Line 795 in 8a5bdd8

if (resultType != numTy)

I believe this is too strict, and needs to be updated to understand that an unknown type parameter can be compatible with a known parameter (in this case fir.char<1,?> is compatible with !fir.char<1,3>).

Is this solution what you would expect?

[jeanPerier]

lieve this is too strict, and needs to be updated to understand that an unknown type parameter can be compatible with a known parameter (in this case fir.char<1,?> is compatible with !fir.char<1,3>).

Is this solution what you would expect?

I agree. In general, I am also a bit worried about FIR/HLFIR operations being too nitpicky about the type extents/lengths in checks. The rational being that inlining may could in the future cause some of the operands type to change and be invalid even if the code as such is not reachable.

Think of:

subroutine foo(c)
 character(*) :: c(10)
 if (len(c) == 3) then
   call some_specialized_version_for_length_3(c)
  else
   call generic_version(c)
 end if
end subroutine

subroutine some_specialized_version_for_length_3(c)
  character(3) :: c(10)
  print *, minval(c)
end subroutine

 character(5) :: c(10)
 call foo(c)
end

If all the functions get inlined and types are propagated, and for some reasons the branch containing the minval call is not pruned, the compiler would throw an internal compiler error for unreachable code that it generated.

This is a lot of ifs, so it is likely OK to keep it as it is, but I would say MLIR verifiers are needed to enforce guarantees that would lead to compiler crash if violated, but that we should rely on semantics/runtime checks for the Fortran constraints that would not prevent the IR to be generated/translated when violated.

[k-arrows]

Thank you for your clarification. I also think the verifier is too strict here. I've tried a few other compilers and none of them complained about this code. But I haven't encountered this problem in a real application, so it doesn't really bother me.

[tblah]

Thanks for the example Jean, that makes a lot of sense. I've made a patch to relax the verifiers.