Question on "Allocate"

[abhimodak]

I searched the forum but I am not sure if the Fortran 2003 standard permits the behavior below--
===============================
Program Test_Allocate
!
! Purpose: Check Allocation.
!
Implicit None
!
Integer, Parameter :: DOUBLE = kind(1.0d0)
Real(DOUBLE), Allocatable :: A(:), B(:), C(:)
!
Integer :: n, ial, idal
!
!###################
!
DeAllocate(A, stat=ial)
print *, ial ! ... [1]

Allocate(A(10), stat=ial)
print *, ial, Size(A) ! ... [2]

Allocate(A(20), stat=ial)
print *, ial, Size(A) ! ... [3]

A(16) = 1.0d0
Print *, A(16) ! ... [4]
!
End Program Test_Allocate
-------------------------------------------------------------------
In the "release" build, the output produced by Intel Fortran 10.0.25 with VS2005 is:
[1] => 153
[2] => 0, 10
[3] => 151, 20
[4] => 1.00000000000

In the debug build, there is warning indicating heap corruption but one can continue.

Abhi

[DavidWhite]

I haven't used Allocate except to test that it works.

I suspect that you should not attempt to Deallocate an array unless it has already been Allocated, such as

IF (.NOT. ALLOCATED(E)) ALLOCATE(E(2:4,7))

Also, I suspect that you should not Allocate an array that is already allocated, so I think your second Allocate statement is in error.

David

[abhimodak]

Hi David

Thanks for your reponse.

I always use the intrinsic function Allocated before allocating or deallocating. However, the above snippet was written intentinally to see how the compiler handles it.

Note that the presence of STAT = variable means program will not terminate. (if stat is excluded, the program will stop when ial /= 0).

The problem with the compiler, I think, is that (1) size of array A is should is allowed to change, and (2) assignment to this array element is seemingly successful.

Before jumping to a conclusion about the compiler, I wanted to check if it is due to Fortran standard being vague about such scenarios.

Abhi

[Steven_L_Intel1]

Very interesting. This is indeed a bug. The standard says that on the second ALLOCATE, since the allocation failed, array A retains its previous allocated status. You are not allowed to "change the size" this way - it is an error to do an ALLOCATE on an object already allocated. The compiler is wrong in changing the size of A. I'll pass this on to the developers.

[jimdempseyatthecove]

Steve,

>>You are not allowed to "change the size" this way - it is an error to do an ALLOCATE on an object already allocated.

On a different thread you stated something different (although the array declaration in that case containd AUTOMATIC).

Do you recall the post? If so, could you clarify?
(and if there is a difference viz. F95/F2003)

Jim

[Steven_L_Intel1]

Jim,

The other post was about passing an array element as an actual argument to a routine which declared the corresponding dummy argument as a different shape. A very different issue.

Here, we have an array that is allocated to a given size and there is a failed attempt to allocate it again (not allowed and this properly gives an error). However, even though the second allocation failed the shape of the array changed, which is just wrong.

[abhimodak]

Hi Steve

Many thanks for confirming my belief that this is a bug. I will also be submitting this to the premier support.

Abhi

[Steven_L_Intel1]

Ok. When you do, please reference T82642-CP. It looks as if this bug has been there for a very long time - CVF has it too.