- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FYI: I submitted this issue to Intel support (Request #03513349).
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page