5b65dbd197
InlineElementals created a regression when inlining elemental expressions where the type of the result of the hlfir.apply does not match the hlfir.yield. This patch ensures the pass doesn't match in these cases, fixing the regression. It isn't clear to me what the /right/ solution is: - Is it actually valid for the hlfir.apply to have a different type (even just different array bounds?). Should this be enforced in the verifier? - Inserting a convert if these types don't match doesn't work because fir.convert doesn't know how to convert a hlfir.expr. Should this be added? Test case is from @vzakhari Differential Revision: https://reviews.llvm.org/D151202
16 lines
511 B
Fortran
16 lines
511 B
Fortran
! RUN: %flang_fc1 -emit-obj -flang-experimental-hlfir -o /dev/null %s
|
|
|
|
! Regression test: ensure we can compile this without crashing
|
|
! this results in a hlfir.elemental with mismatched types in the hlfir.apply
|
|
! and hlfir.yield
|
|
subroutine test
|
|
interface
|
|
function func(i,j,k)
|
|
character(5),allocatable :: func(:,:,:)
|
|
end function func
|
|
end interface
|
|
character(13),allocatable :: a(:,:,:)
|
|
print *, (func(2,5,3)//reshape([(char(ichar('a')+n),n=1,2*5*3)], &
|
|
& [2,5,3]))
|
|
end subroutine test
|