There seems to be a problem with the use of elemental intrinsic functions in the dimension specification of an derived type. The following code compiles with an internal error when an instance of a previous (erroneous) declared type is used as dummy variable .
module mdl implicit none save integer, parameter :: ng=10, dp=8 type grid_f(g_size) integer, len :: g_size real(dp), dimension(max0(2*g_size+10, g_size)) :: val end type contains subroutine grid_reset(func) implicit none type(grid_f(ng)) :: func func%val=0d0 end subroutine grid_reset_orb end module mdl
The compilation gives:
ifort -c check.f90 check.f90(10): error #7974: An elemental intrinsic function here must be of type integer and each argument must be an initialization expression of type integer or character. [MAX0] real(dp), dimension(max0(2*g_size+10, g_size)) :: val --------------------------^ check.f90(17): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance. type(grid_f(ng)) :: func ^ [ Aborting due to internal error. ] compilation aborted for check.f90 (code 1)
Using jmax0 or max instead of max0 does not change the behavior. According to this site max0 takes and results in int(4) and should thus be compliant with dimension().
The internal error is in ifort v16 and v17, but fixed in v18 and v19. However, ifort still vetoes the code. Nagfor and gfortran accept the code. I'd have to dig into the standard to see whether the code is really compliant. If so, this should be an intel bug.
I agree that this code is standard-conforming. I recall seeing a similar bug with length type parameters a few months ago. Please report it to Intel. In this context, the use of MAX is in a specification expression, not a constant expression (formerly called "initialization expression").
F2008 (126.96.36.199) says: "A type parameter may be used as a primary in a specification expression (7.1.11) in the derived-type-def ."