Deallocate bug

[Ian_Thompson]

This program generates a run-time error.

[fortran]program ifort_bug

implicit none

type :: token
  type (token)  , pointer :: next => null()
end type

type  (token) , pointer :: first

class (token) , pointer :: q

allocate( first )
allocate( first % next )

q => first % next
deallocate( q )
write (*,*) "OK"

end program[/fortran]

Terminal i/o is as follows:

[mait-mac:polygone/v3/intel_bug3] mait% ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.1.246 Build 20111011
Copyright (C) 1985-2011 Intel Corporation. All rights reserved.

[mait-mac:polygone/v3/intel_bug3] mait% ifort ifort_bug.f90
[mait-mac:polygone/v3/intel_bug3] mait% a.out
forrtl: severe (173): A pointer passed to DEALLOCATE points to an array that cannot be deallocated
Image PC Routine Line Source
a.out 000000010B3103D4 Unknown Unknown Unknown
a.out 000000010B30EB6E Unknown Unknown Unknown
a.out 000000010B2EA971 Unknown Unknown Unknown
a.out 000000010B2C061E Unknown Unknown Unknown
a.out 000000010B2D8B10 Unknown Unknown Unknown
a.out 000000010B2BCCF0 Unknown Unknown Unknown
a.out 000000010B2A7E96 Unknown Unknown Unknown
a.out 000000010B2A7D7C Unknown Unknown Unknown
a.out 000000010B2A7D34 Unknown Unknown Unknown

[sugimoto605]

You may declare pointer q as
type (token),pointer::q

If you want to use polymorphic variable,
select type statement is required:

class (token) , pointer :: q
type (token) , pointer :: p
...
q => first % next
select type (q)
type is (token)
p=>q
deallocate( p ) ! p is type(token) so you can deallocate it
write (*,*) "OK"
end select

[Steven_L_Intel1]

The standard says "If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object that was created by allocation. The pointer shall have the same dynamic type and type parameters as the allocated object, and if the allocated object is an array the pointer shall be an array whose elements are the same as those of the allocated object in array element order." Ian's program meets this test - pointer Q has the same dynamic type as first%next. I will take this up with the developers, though the workaround of a SELECT TYPE is useful.

[Steven_L_Intel1]

Escalated as DPD200177493.

[Steven_L_Intel1]

We have fixed this - I'll let you know if the fix will be going into a 12.1 update (seems likely to me.) This particular problem occurs only when the pointer is scalar and polymorphc and the target is scalar and NOT polymorphic. The compiler does not currently look at the dynamic types of the operands.

Separately, we are going to add the test for "same dynamic type", but that will come later.

[Steven_L_Intel1]

The fix for the unwarranted error should appear in Update 9, scheduled for February.