Unexpected disassociation of polymorphic components

[tplaakso]

Hello,

On execution,

[fortran]program test
  
  type :: one
     real, allocatable :: r
  end type one

  type :: two
     type(one), pointer  :: t
     class(one), pointer :: c
  end type two

  type(two) :: x

  x = f()
  print *,associated(x%t), associated(x%c)

contains

  function f()
    type(two) :: f
    allocate(f%t, f%c)
  end function f

end program test
[/fortran]

displays

[fortran][merry] misc > ifort -free intel_pointer_test.f
[merry] misc > ./a.out 
 T F
[/fortran]

using the latest compiler on OSX. I am under the impression that pointer association should not be lost (or can this be explained by some automatic deallocation process?).

Teemu Laakso

[Steven_L_Intel1]

The pointer association is not being lost, nor is there any deallocation going on. But ASSOCIATED is returning the wrong result for a polymorphic pointer after assignment. I will report this to the developers. Issue ID is DPD200176219.

[tplaakso]

OK, thanks for taking this forward, but I do not think that the problem is only ASSOCIATED giving the wrong result, since

[fortran]program test
  
  type :: one
     real, allocatable :: r
  end type one

  type :: two
     type(one), pointer  :: t
     class(one), pointer :: c
  end type two

  type(two) :: x

  x = f()
  print *,associated(x%t), associated(x%c)
  print *,x%t%r
  print *,x%c%r

contains

  function f()
    type(two) :: f
    allocate(f%t, f%c)
    f%t%r = 1.0
    f%c%r = 2.0
  end function f

end program test
[/fortran]

yields

[fortran][merry] misc > ifort -free -standard-semantics intel_pointer_test.f
[merry] misc > ./a.out 
 T F
 1.000000
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
a.out              0000000100000B2C  Unknown               Unknown  Unknown
a.out              000000010000088C  Unknown               Unknown  Unknown

Stack trace terminated abnormally.
[/fortran]

Maybe it is worth noting that if "allocatable" is removed from the definition of "r" in type "one", everything works. Also, if the order of the definitions of "t" and "c" in type "two" is exchanged, the ASSOCIATED(x%c) returns true, but the segfault still persists.

Teemu

[Steven_L_Intel1]

You are correct - the failure of ASSOCIATED is a symptom, not the actual problem. I suspect the underlying cause is that all the fields of the pointer descriptor are not being filled in when there is a polymorphic component during the intrinsic assignment of a pointer.

[tplaakso]

Well, according to my experiments the intrinsic assignment fails when the polymorphic component has dynamically allocated components ("r" in "one" is either allocatable/pointer). The simplest workaround that I can think of, with similar functionality, is to replace the assignment by a pointer assignment:

[fortran]program test
  
  type :: one
     real, allocatable :: r
  end type one

  type :: two
     type(one), pointer  :: t
     class(one), pointer :: c
  end type two

  type(two), pointer :: x

  x => f()
  print *,associated(x%t), associated(x%c)
  print *,x%t%r
  print *,x%c%r

contains

  function f()
    type(two), pointer :: f
    allocate(f)
    allocate(f%t, f%c)
    f%t%r = 1.0
    f%c%r = 2.0
  end function f

end program test
[/fortran]

However, since this requires more that just one line commented out and replaced by another, I think that this bug is quite nasty (compared to the other ones which have affected my development recently).

Teemu

[tplaakso]

While exploring another workaround by overloading the instrinsic assignment with a defined one, as in

[fortran]module types

  type :: one
     real, allocatable :: r
  end type one

  type :: two
     type(one), pointer  :: t
     class(one), pointer :: c
  end type two

  interface assignment(=)
     module procedure sub
  end interface assignment(=)

contains

  subroutine sub(x,y)
    type(two), intent(out) :: x
    type(two), intent(in)  :: y
    print *,associated(y%t),associated(y%c),y%t%r,y%c%r
    allocate(x%t)
    print *,'x%t allocated'
    allocate(x%c, source=y%c)
    print *,'x%c allocated'
    x%t%r = y%t%r
    x%c%r = y%c%r
  end subroutine sub

end module types

program test
  
  use types

  type(two) :: x

  x = f()

contains

  function f()
    type(two) :: f
    allocate(f%t, f%c)
    f%t%r = 1.0
    f%c%r = 2.0
  end function f

end program test
[/fortran]

I found out that this does not work either:

[plain][merry] misc > ./a.out 
 T T 1.000000 2.000000
 x%t allocated
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
a.out              00000001000157A5  Unknown               Unknown  Unknown
a.out              000000010001564F  Unknown               Unknown  Unknown
a.out              0000000100000A63  Unknown               Unknown  Unknown
a.out              000000010000075C  Unknown               Unknown  Unknown
a.out              0000000100000714  Unknown               Unknown  Unknown
[/plain]

Supposing that this should work, I do not know if it represents a related, or a new issue.

Teemu

[Steven_L_Intel1]

I expect the fix for the original issue to appear in Update 9. The latest program is a different problem, involving ALLOCATE(SOURCE=), yet to be fixed. That issue ID is DPD200177633.

[tplaakso]

OK. The first code example in this thread seemingly works using Update 9. Both calls to ASSOCIATED return TRUE. However, the second code example still gives the segmentation fault. Could it be that the "fix" is not of the highest quality?

best regards,
Teemu

[Steven_L_Intel1]

No, the second example is a different problem, as in function f the component f%c%r is not getting allocated. My apologies for not reporting that one earlier - it has been escalated as DPD200179234.

[tplaakso]

No problem, I am sure this will work eventually. About f%c%r not getting allocated, I wish to comment that printing ALLOCATED(f%c%r) or ALLOCATED(x%c%r) in proper places return all TRUE for me (in the second example).

Teemu