- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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
===============================
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
링크가 복사됨
7 응답
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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
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
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
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.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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.
