topic Internal Error, request to have compiler show context of SIGSEG in Intel® Fortran Compiler

Internal Error, 11.1.073 (Linux X64), 11.1.067 (Win 32), 11.1.072 (Linux IA64) compilers

mecej4 — Thu, 21 Oct 2010 17:42:28 GMT

IFORT 11.1.073 on Linux, 11.1.067 on WXP-32 and 11.1.072 on Linux-IA64 causes an illegal access (C0000005 on Windows, SIGSEG on Linux) crash compiling this source code:

[fortran]MODULE DPTYPE
   IMPLICIT NONE
   INTEGER, parameter :: dp = kind(1.0d0)
END MODULE DPTYPE
!
MODULE S_QHF
   INTERFACE
      SUBROUTINE QHF(Mtyp,M,N,Const,Diag,A,Lda)
      USE DPTYPE
      IMPLICIT NONE
      REAL(dp) :: Const , Diag
      INTEGER :: Lda , M , N
      CHARACTER(len=1) :: Mtyp
      REAL(dp) , DIMENSION(Lda,*) :: A
      INTENT (IN) :: Const , Diag , Lda , M , Mtyp , N
      INTENT (IN OUT) :: A
      END SUBROUTINE QHF
   END INTERFACE
END MODULE S_QHF
[/fortran]

The problem goes away if the INTENT specifications on lines 15 and 16 are removed or merged into the respective type declarations.

Internal Error, 11.1.073 (Linux X64), 11.1.067 (Win 32), 11.1.0

Steven_L_Intel1 — Mon, 25 Oct 2010 21:06:09 GMT

Thanks - we'll take a look.

Internal Error, request to have compiler show context of SIGSEG

mecej4 — Tue, 26 Oct 2010 14:45:10 GMT

Thanks, Steve.

This may be an apt moment to request a small "feature". The code that produced the ICE was actually a small bit of a much larger file that contained about a hundred INTERFACE declarations for the subroutines and functions of a project, with the structure:

Module A_S
Interface
Subroutine A(...)
...
End Subroutine A
End Interface
End Module A_S
...
Module M_S
Interface
Subroutine M(...)
...
End Subroutine M
End Interface
End Module M_S
...
Module Z_S
Interface
Subroutine Z(...)
...
End Subroutine Z
End Interface
End Module Z_S

The ICE was triggered by the code in module M_S, but the error message gave me no clue as to which interface declaration was triggering the ICE. This was despite the compiler being able to intercept the SIGSEG.

I feared that I would have to split the source into the ~100 pieces and try the compiler on each module source. Fortunately, I did not have to do so.

Apparently, the compiler writes and closes each module file as soon as it can, rather than buffering the output. Thus, I did a directory listing of the module files sorted by file-modification time, and identified the module source next in sequence in the source file after the last one that was successfully compiled. With my example above, I would see A_S.mod,..., L_S mod, but no M_S mod, etc.

The request: please have the compiler report the context (by line-number, or module/subprogram name) corresponding to the intercepted SIGSEG.

Internal Error, request to have compiler show context of SIGSEG

Steven_L_Intel1 — Tue, 26 Oct 2010 15:11:49 GMT

ICE reported as issue DPD200162164. I will also request more information when an error occurs - this would be helpful to us as well.

Internal Error, request to have compiler show context of SIGSEG

Steven_L_Intel1 — Thu, 14 Apr 2011 15:43:59 GMT

I expect the fix for this to appear in Update 4.