Assignment of derived type with allocatable class component

[IanH]

Apologies if this has already been covered with the other polymorphic feature discussions.

Is the subject line supported in 11.1? If not, is it supported in the next (Novemberish) major release?

For example, the following dies at runtime using 11.1.067 with /check:all /warn:all with a "pointer ITEM ... not associated" error. But I think the code is legitimate.

[fortran]PROGRAM a_classy_assignment
  IMPLICIT NONE
  TYPE :: parent
    INTEGER :: comp
  END TYPE parent  
  TYPE wrapper
    CLASS(parent), ALLOCATABLE :: item
  END TYPE wrapper
  TYPE(wrapper) :: a
  TYPE(wrapper) :: b  
  !***  
  ALLOCATE(parent:: a%item)
  a%item%comp = 123    
  b = a  
  PRINT "(I0)", a%item%comp   ! 123
  PRINT "(I0)", b%item%comp   ! Boom.  
END PROGRAM a_classy_assignment[/fortran]

[mecej4]

You are probably more knowledgeable on the topic of polymorphic variables in Fortran than me, so I ask that you look at section 7.4.1.2 of the standard, which says

...In an intrinsic assignment statement, variable shall not be polymorphic...

If I am not misreading this statement, line 14 of your program violates this rule. The compiler could flag this violation, instead of producing code that causes a run-time crash.

[Steven_L_Intel1]

I don't think the program violates the rule. b is not polymorphic - it's TYPE(wrapper). The assignment b=a should automatically allocate b%item to be the same dynamic type as a%item. See p141, lines 14-25 of F2003.

I tried the program with pointer checking in the next major release and it executed without error.

[IanH]

Thanks for the responses. My steps in polymorphic-land aren't exactly confident.

Roll on November(ish)!

[IanH]

Apologies for the old thread bump, but 12.0.3 (and maybe earlier) don't seem to be playing ball with the original example. The pointer checking error has gone but the value being assigned is nonsense.

[fortran]>ifort /check:all /warn:all /standard-semantics poly-comp-assign.f90
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 1
2.0.3.175 Build 20110309
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

Microsoft  Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:poly-comp-assign.exe
-subsystem:console
poly-comp-assign.obj


>poly-comp-assign
123
0[/fortran]

(Expected 123 twice).

An alternative example: poly-comp-assign-2.f90

Larger examples show that all is not well in polymorphic component land. It's easy enough to work around the assignment issue above, but then I hit a memory leak that's got me stumped (calling deallocate on a polymorphic component doesn't deallocate that component?). Work around suggestions appreciated.

poly-comp-leak.f90

(I'd raise similar issues with finalisation of derived type components, if I had any confidence about my understanding of who/when and where such finalisation should occur...)

[Steven_L_Intel1]

Ian,

As you note, assignment to a polymorphic variable is not standard F2003 but is standard F2008. The Intel compiler does not support this yet, but fails to complain about a polymorphic component as it does for a polymorphic variable. I have reported this to developers as DPD200167981. I assume that we'll either implement the feature or give an error message.

I have not looked at your example of finalization, but I know there has been some vigorous debate among the standards committee members on this topic and I think interpretations have been submitted. When I get a chance I'll look into this further.

[IanH]

Thanks.

To clarify - the assignment issue is as per your post #2 - the variable being assigned to is not polymorphic, but the variable has a component that is polymorphic. I think the behaviour is all well defined by F2003 given the excerpt you quoted. I can work around that by defining a "Clone" type bound procedure that simulates the assignment of the component.

The other example is a memory leak that occurs when polymorphic components are used. When you deallocate the parent (non-polymorphic) variable it doesn't appear that cleanup is done on the components. Perhaps this is related to http://software.intel.com/en-us/forums/showpost.php?p=101350.

I'll put the finalization stuff in another post, because that might have more to do with my language understanding than suspected compiler issues.

[Steven_L_Intel1]

When I had quoted the standard earlier, I somehow missed that type WRAPPER had a polymorphic component. That is not supported by Fortran 2003 for intrinsic assignment.

[IanH]

Are you sure? The text that you quoted (p141, lines 14 to 25) in the draft has a pretty complete description of the steps that happen for an allocatable component when the containing derived type is assigned. Talks about deallocation, reallocation to the same dynamic type, intrinsic assignment per that dynamic type, etc. If it doesn't cover polymorphic components then it's a bit odd that it talks about dynamic type.

[Steven_L_Intel1]

Sorry, my error. You are correct and I have let the developers know (indeed one already told me I was wrong...)

[Steven_L_Intel1]

This has been fixed for a release later this year.