Consider a function returning a parameterised derived type that depends on inputs to set its parameter length. Such a use seams the most logical way to use this feature. This example is part of some AD code I suspect many will attempt:
module Bar
implicit none
integer, parameter :: DP = 8
type Foo(n)
integer, len :: n
real(DP) :: v
real(DP) :: d(n)
end type
contains
function divide(a, b) result(c)
type(Foo(*)), intent(in) :: a
type(Foo(*)), intent(in) :: b
type(Foo(a%n)) c
c%v = a%v/b%v
c%d = (a%d - a%v*b%d/b%v)/b%v
end function
subroutine divideSub(a, b, c)
type(Foo(*)), intent(in) :: a
type(Foo(*)), intent(in) :: b
type(Foo(a%n)), intent(out) :: c
c%v = a%v/b%v
c%d = (a%d - a%v*b%d/b%v)/b%v
end subroutine
end module
program test
use Bar
implicit none
type (Foo(n=100)) :: x, y, z
x%v = 1.0d0
x%v = 1.0d0
y%v = 2.0d0
y%d = 0.0d0
z = divide(x, y)
call divideSub(x, y, z)
end program
If gives:
1>------ Build started: Project: TestDerivedTypeCompilerCrash, Configuration: Debug Win32 ------
1>Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]...
1>Source1.f90
1>Bla\Bla\Source1.f90(42): error #6197: An assignment of different structure types is invalid.
1>Bla\Bla\Source1.f90(43): error #6633: The type of the actual argument differs from the type of the dummy argument. [Z]
1>compilation aborted for Bal\Bla\Source1.f90 (code 1)
1>
1>Build log written to "file://Bla\Bla\BuildLog.htm"
1>TestDerivedTypeCompilerCrash - 3 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
The problem appears to arise because the return type of the function is not explicit and so can not be assumed to match the type of the local variable we assign it to. The same problem arises for a subroutine version with an intent(out) result.
The compiler must be intelligent enough to work through the function call to determine the implied result type but has not done so. With these severe limitations of the 16.0 compiler we have very little we can usefully do with parameterised derived types apart from declare a few just for fun. Will Intel attempt to fix this issue soon ?
