Type bound procedures fail with allocatable components

[fercook]

Hello,

I have a derived type with an allocatable component. Because of this, the compiler enters into some infinite loop while increasing memory usage. I checked that if I use a normal (non-allocatable) component everything compiles and runs fine. The type-bound functions that cause the problem can be called directly, it is the

type%procedure()

syntax that gives problems.

Below is a test case that shows the problem. It is a little long because the allocatable component requires an explicit constructor and printing routines.

I repeat, if the commented line is uncommented, the following code breaks the compiler (no error message is generated).

[fortran]module mytype_class

	type mytype
		integer,allocatable :: int(:)
	contains
		procedure :: aFunction => the_Function
		procedure :: aSubroutine => the_Subroutine
		procedure :: print => my_print
	end type mytype

  contains

	function new_mytype(dim) result(this)
		integer :: dim,n
		type(mytype) :: this
			allocate(this%int(dim))
			do n=1,dim
				this%int(n)=n
			enddo
	end function

	subroutine my_print(this)
		class(mytype) :: this
			print *,this%int
	end subroutine

  	subroutine the_Subroutine(this)
  		class(mytype),intent(INOUT) :: this
    		this%int=2*this%int
  	end subroutine

  	function the_Function(this) result(newone)
  		class(mytype),intent(INOUT) :: this
  		type(mytype) :: newone
 			this%int=2*this%int
 			newone=new_mytype(size(this%int))
 			newone%int=2*this%int
	end function

end module mytype_class


program TestTypeBoundProcs
    use mytype_class

    implicit none

    type(mytype) :: A,C
	A=new_mytype(3)

	call A%print()
	call A%aSubroutine()
	call A%print()

!	C=A%aFunction()		!THIS FREEZES THE COMPILER
	C=the_Function(A)       !THIS IS EQUIVALENT BUT WORKS
	call A%print()
	call C%print()

end program TestTypeBoundProcs
[/fortran]

I read in the documentation that type bound procedures are supported, but not type bound operators nor generics. Can somebody explain me what is the difference between a type bound operator and a generic operator?

I am using IFort 11.1.088 on Mac OS X 10.6

[Izaak_Beekman]

I thought I was seeing something similar, but managed to fix the code to an acceptable state. I am unsure as to whether the issue I was seeing was because of my lacking understanding of some Fortran 2003 subtleties when using allocatable scalars, and objects with allocatable components as dummy arguments or whether it was compiler related. I was passing an allocatable scalar to a type bound procedure, with INTENT(inout) and testing the allocation status inside the procedure. The idea was to leave it be and do one thing if it was allocated, or allocate it and do something else if it wasn't. In the end I just gave it INTENT(OUT) and reset the object. Any way, i digress....

Changing the_Function to a subroutine might fix the problem. It's a bit odd anyway to have a procedure like this which is a function that returns a value and modifies it's sole argument. Although, as far as i can tell it does look like valid F2003. I'll be curious what other people have to say.

[Kevin_D_Intel]

Thank you for the convenient reproducer (not long by any standard). The line noted clearly sends the compiler into an infinite allocation loop that should not occur. I directed the issue to Development (refer to internal tracking id below) and will update this thread as I learn more.

I have to defer your question about the difference between "a type bound operator and a generic operator" to others here who are more knowledgeable and may be able to answer. I did also include your question in the report to Development and will share any details provided.

(Internal tracking id: DPD200156693)

(Resolution Update on 11/30/2010): This defect is fixed in the Intel Fortran Composer XE 2011 initial release (12.0.0.085 - Mac OS)

[Steven_L_Intel1]

Just as you can declare your own generic interfaces and user-defined operators, the F2003 standard allows you to do this with type-bound procedures, so that instead of having to reference a specific function name you can use a generic name and optionally an operator or assignment instead of a function name. These features are expected to be supported in the next major release.

[fercook]

zbeekman said: It's a bit odd anyway to have a procedure like this which is a function that returns a value and modifies it's sole argument.

Yes, I kind of agree. In my project I have a container of objects, where each can be put in a normal form. The type bound function object%Normalize() looks like a natural piece of code. It could be a subroutine, however, each normalize operation produces another kind of object that I must use to normalize the next object in the list. Then, I ended up with a function that does something to its object and also returns a different type of object. Since we are both digressing...do you have any suggestion for a more understandable design?

[fercook]

Thanks Kevin and Steve ! I look forward to the next versions of IFort.

[Kevin_D_Intel]

I confirmed the defect leading to the compile-time infinite allocation loop is fixed in the next major release due out late this year.

[Kevin_D_Intel]

The Intel Fortran Composer XE 2011 initial release (12.0.0.085 - Mac OS) with the fix is available from the Intel Registration Center: https://registrationcenter.intel.com

The test case now compiles successfully.

$ ifort -V -c u75310.f90

Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.0.085 Build 20101006
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

Intel Fortran 12.0-1176