Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Catastrophic error

Jacob_Williams
New Contributor I
1,030 Views

The following code produces a "catastrophic error: **Internal compiler error: internal abort**" with the Intel Fortran compiler (2017 and 2018):

module test_module

use, intrinsic:: iso_c_binding

implicit none

procedure(func),public,pointer :: f => null()

abstract interface
    type(c_ptr) function func(p) bind(c)
    import :: c_ptr
    implicit none
    type(c_ptr),intent(in) :: p
    end function func
end interface

contains

logical function register( callback ) bind(c, name='register')
!DEC$ ATTRIBUTES DLLEXPORT :: register
procedure(func) :: callback
f => callback
register = .true.
end function register

end module test_module

 

0 Kudos
8 Replies
Steve_Lionel
Honored Contributor III
1,030 Views
0 Kudos
mecej4
Honored Contributor III
1,030 Views

Compiles, no problems, with 17.0.7 and 18.0.3 on Windows-64.

P.S. I used the 32-bit target here. Later, I tried the 64-bit target, and did see the ICE.

0 Kudos
emanspeaks
Beginner
1,030 Views

Using VS2013 Pro, it fails with the following output for me:

1>------ Build started: Project: Dll1, Configuration: Debug x64 ------
1>Compiling with Intel(R) Visual Fortran Compiler 18.0.3.210 [Intel(R) 64]...
1>Source1.F90
1>0_1855
1>C:\Users\raeckman\git\copernicus-devel-test\Dll1\Dll1\Source1.F90(22): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
1>compilation aborted for C:\Users\raeckman\git\copernicus-devel-test\Dll1\Dll1\Source1.F90 (code 1)
1>
1>Build log written to  "file://C:\Users\raeckman\git\copernicus-devel-test\Dll1\Dll1\x64\Debug\BuildLog.htm"
1>Dll1 - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Note that line 22 is where the pointer assignment is made.

0 Kudos
Jacob_Williams
New Contributor I
1,030 Views

I get this error with ifort 17.0.2, and a colleague gets the same error with ifort 18.0.3 (Windows, 64 bit, Visual Studio 2013). Are you saying it works for you with 18.0.3? 

0 Kudos
mecej4
Honored Contributor III
1,030 Views

I checked various combinations. No ICE with 18.0.3 when targeting IA-32, various versions of VS.

Now that I tried targeting x64, I do see the ICE.

0 Kudos
FortranFan
Honored Contributor II
1,030 Views

@Jacob WIlliams,

You should report the ICE (always a compiler bug) to Intel support at https://supporttickets.intel.com/?lang=en-US. ; As indicated by @mecej4, the ICE occurs with x64 target and it persists with Intel Fortran compiler 18.0 update 3 as well as 19.0 BETA update 1.

Now for the code you show to more strictly follow the standard facilities with enhanced interoperability with C would require one to use a type of C_FUNPTR with the dummy argument and C_F_PROCPOINTER in the offending subprogram with C binding.  This avoids the ICE with all versions of Intel Fortran I tried, so it can be an option to consider:

module test_module

   use, intrinsic:: iso_c_binding, only : c_bool, c_ptr, c_funptr, c_f_procpointer

   implicit none

   procedure(func), public, pointer :: f => null()

   abstract interface
      type(c_ptr) function func(p) bind(c)
         import :: c_ptr
         implicit none
         type(c_ptr), intent(in) :: p
      end function func
   end interface

contains

   function register( callback ) result(r) bind(c, name='register')
   !DEC$ ATTRIBUTES DLLEXPORT :: register
      ! Argument list
      type(c_funptr), value, intent(in) :: callback
      ! Function result
      logical(c_bool) :: r
      
      call c_f_procpointer( cptr=callback, fptr=f )
      r = .true.
      
   end function register

end module test_module

 

0 Kudos
Jacob_Williams
New Contributor I
1,030 Views

@FortranFan Thanks! That is a good tip. I'll look into it.

FYI: what we are doing now works fine for subroutine callbacks, but functions cause the ICE.

0 Kudos
Jacob_Williams
New Contributor I
1,030 Views

FYI: I submitted this issue to Intel support (Request #03513349).

0 Kudos
Reply