INTENT(OUT) in type-bound procedures

[John4]

When I run the code below (compiled with ifort 11.1 Update 4), I get 400 printed three times. Is it a bug, or is the compiler right at ignoring the initialization for a polymorphic argument?

!------------------------------------------------------------------------------
module mod1

implicit none
private
save

type, public :: t1
integer :: item = 300
contains
procedure :: destroy
end type

contains
subroutine destroy(this)
class(t1), intent(OUT) :: this
print *, this%item
end subroutine

end module mod1

program test

use mod1

implicit none

type(t1) :: a

continue

a%item = 400

print *, a%item

call a%destroy()

print *, a%item

end program test
!------------------------------------------------------------------------------

[IDZ_A_Intel]

That's a good question. Off the top of my head, I'd call this a compiler bug but I need to research it some more. If "this" were declared type(t1), then item should definitely be reset to 300 on entry to destroy, but I'm unsure about the effect of it being polymorphic. Stay tuned.

[abhimodak]

Hi

While Steve comes back with the authoritative answer, I looked through the F2003 handbook (by Adams et al) and 95/2003 book by Metcalf et al to see if there are any exceptions to the Intent(OUT) when the object is polymorphic. But I did not find any. It would be a surprise if there was.

On the other hand: On page 238, chapter 7, of the handbook by Adams a special note is made about vector v (which is a polymorphic argument) being deallocated on entry because it is intent(out). Thus, this is a compiler bug.

Unfortunately, since update 4 messes up the debugger, it is not possible to step into the type-bound procedure and see the value of the variable to look/verify the behavior of intent(OUT).

Abhi

p.s. for whatever it is worth, running this snippet with IBM XLF v11 gives: 400, 300, 300 which is the correct answer.

[IDZ_A_Intel]

Reported to development as issue DPD200150651. I believe that CLASS(*) should also work here (it doesn't at present.)

[IDZ_A_Intel]

This has proven to be a complex issue that required inventing new mechanisms in the compiler and run-time library. We have done this for a future release.

[Steven_L_Intel1]

This was fixed in 13.0.