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

Compiler bug: Repeated polymorphic assignment raises run-time error

Balint_Aradi
New Contributor I
1,158 Views

Dear all,

the current Intel compiler (ifort (IFORT) 2021.4.0 20210910 on x86_64.Linux) produces a badly behaving binary for the code below. The code is, as far as I can judge, standard conforming, but when executing the produced binary, I get a run-time error and the code stops.

 

module test
  implicit none

  type :: base_t
  end type base_t

  type, extends(base_t) :: extended_t
    integer :: ii
  end type extended_t

contains

  subroutine pop(item)
    class(base_t), allocatable, intent(inout) :: item
    class(base_t), allocatable :: buffer
    call move_alloc(item, buffer)
  end subroutine pop

end module test


program testprog
  use test
  implicit none

  class(base_t), allocatable :: base

  base = extended_t(41)
  call pop(base)
  base = extended_t(42)
  print *, "DONE"

end program testprog

 

The resulting binary stops with the run-time error

 

forrtl: severe (122): invalid attempt to assign into a pointer that is not associated
Image              PC                Routine            Line        Source             
a.out              0000000000407A56  Unknown               Unknown  Unknown
a.out              0000000000403FA2  Unknown               Unknown  Unknown
a.out              0000000000403862  Unknown               Unknown  Unknown
libc-2.31.so       00007F5C8FC1E0B3  __libc_start_main     Unknown  Unknown
a.out              000000000040376E  Unknown               Unknown  Unknown

 

Interestingly, when I comment out the pop() call, the program runs without errors, so I guess, something bad happens to the descriptor of base, when it is passed forth and back in the call.

0 Kudos
3 Replies
Balint_Aradi
New Contributor I
1,151 Views

Actually, it seems, that it is the move_alloc(), which leaves the descriptor in a bad state. The following simplified example generates the same behavior:

program testprog
  implicit none

  type :: base_t
  end type base_t

  type, extends(base_t) :: extended_t
    integer :: ii
  end type extended_t

  class(base_t), allocatable :: base, buffer

  base = extended_t(41)
  call move_alloc(base, buffer)
  base = extended_t(42)
  print *, "DONE"

end program testprog

 

0 Kudos
Devorah_H_Intel
Moderator
1,092 Views

Thank you for the report. This issue is now escalated to compiler engineering. 

0 Kudos
Devorah_H_Intel
Moderator
841 Views

This issue has been fixed in the current oneAPI 2023.

0 Kudos
Reply