Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26731 Discussions

ifort16: internal error using elemental intrinsics in dimension specifier

K__Alex1
Beginner
197 Views

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().
Any suggestions?

0 Kudos
2 Replies
Juergen_R_R
Valued Contributor I
197 Views

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. 

Steve_Lionel
Black Belt Retired Employee
197 Views

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 (4.5.3.1) says: "A type parameter may be used as a primary in a specification expression (7.1.11) in the derived-type-def ."

Reply