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!

Catastrophic error

Jacob_Williams
New Contributor I
303 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
Black Belt Retired Employee
303 Views
mecej4
Black Belt
303 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.

emanspeaks
Beginner
303 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.

Jacob_Williams
New Contributor I
303 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? 

mecej4
Black Belt
303 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.

FortranFan
Honored Contributor II
303 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

 

Jacob_Williams
New Contributor I
303 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.

Jacob_Williams
New Contributor I
303 Views

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

Reply