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

Compiler bug: Procedure pointer association status gets lost

Balint_Aradi
New Contributor I
833 Views

The Intel oneAPI Fortran compiler (ifx (IFX) 2024.2.0 20240602 on x86_64/Linux) produces erroneous executable, where an associated procedure pointer loses its association under certain conditions. Below the MWE example extracted from the Fortuno unit testing framework, demonstrating the issue:

 

module test_generator
  implicit none

  type :: serial_case_base
    character(:), allocatable :: name
  end type

  type, extends(serial_case_base) :: serial_case
    procedure(argless_proc), pointer, nopass :: proc => null()
  end type serial_case

  abstract interface
    subroutine argless_proc()
    end subroutine argless_proc
  end interface

  type :: test_item
    class(serial_case_base), allocatable :: item
  end type

contains

  function get_tests() result(testitems)
    type(test_item), allocatable :: testitems(:)

    testitems = [test_item(serial_case(name="proc_call", proc=test_proc_call))]

    ! Test, wether procedure can be called
    select type (p => testitems(1)%item)
    type is (serial_case)
      print *, "1:START calling proc()"
      call p%proc()
      print *, "1:END calling proc()"
    end select

  end function get_tests


  subroutine test_proc_call()
    print *, "hello from test_proc_call"
  end subroutine test_proc_call

end module test_generator


program testapp
  use test_generator, only : get_tests, test_item, serial_case
  implicit none

  type(test_item), allocatable :: testitems(:)

  testitems = [get_tests()]

  ! Test, wether procedure can be called
  select type (p => testitems(1)%item)
  type is (serial_case)
    print *, "2:START calling proc()"
    call p%proc()
    print *, "2:END calling proc()"
  end select

end program testapp
  

Compiling the code with ifx (without any options) and executing it results in a segfault with following output:

1:START calling proc()
 hello from test_proc_call
 1:END calling proc()
 2:START calling proc()
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          00007F1766F56710  Unknown               Unknown  Unknown
a.out              0000000000404A98  Unknown               Unknown  Unknown
libc.so.6          00007F1766F56710  Unknown               Unknown  Unknown

 The code is standard conforming as far as I can see, and other compilers (e.g. NAG, GNU) seem to have no problems to generate a non-segfaulting executable.

 

A few additional observations:

  • The first call test at line 33 works out as supposed. It is the test at line 59, which causes the segfault.
  • Leaving away the array constructor at line 53 (using "testitems = get_tests()" instead of "testitems = [get_tests()]") results in a working executable.
  • Moving the definition of the field "name" into the extending type (serial_case) results in a correctly working executable.
  • Removing the definition of the field "name" (and adapting the structure constructor in line 27 accordingly) also leads to a working executable.
0 Kudos
6 Replies
Ron_Green
Moderator
704 Views

I see this error also.  It seems to be a change between the 2024.0.0 and the 2024.1.0 compiler that broke.

I will get a bug report started.

 

the 2023.2.0 or 2024.0.0 compiler works for this example.

Balint_Aradi
New Contributor I
688 Views

Yes, indeed, with 2024.0 we had no problems. Thanks for taking care about it (it is unfortunately a showstopper for Fortuno).

0 Kudos
Balint_Aradi
New Contributor I
543 Views

Please note, that 2024.2 (ifx (IFX) 2024.2.1 20240711) still contains this bug. Any chance, that it will be soon fixed?

0 Kudos
Devorah_H_Intel
Moderator
513 Views

@Balint_Aradi  I will check the status and update you soon. 

0 Kudos
Devorah_H_Intel
Moderator
373 Views

This issue is not fixed yet. However we are planning on fixing it in future compiler releases. 

0 Kudos
Ron_Green
Moderator
352 Views

the fix for this did not make the upcoming 2025.0 release.  However, it is fixed in 2025.1 which is our active branch.  That 2025.1 release should release in roughly late March or April 2025. 

Reply