- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I would like to know in what situations /check:pointer will help trap mistakes. The tooltip says that it will catch disassociated or uninitialized pointers and allocatable arrays. Does it mean "undefined" pointers by any chance?
For example, in the snippet below, the pointer m's status at [1] is undefined since it is not NULL-initialized while at [2] it is undefined because the target has been deallocated.
/check:pointer does not catch this. Is it expected to? Also, the associate contruct at [3] is also illegal.
{As far as I know, I don't think the standard specifies anything that compiler should do and one can expect unexpected results. I am wondering, however, if there is a way.}
===========
Program Test_UndefinedPointers
Implicit None
Integer, Allocatable :: n(:)
Integer :: ial, j
Integer, Pointer :: m(:) !=> Null()
Target :: n
!Nullify(m)
Print *, "Is pointer associated?", Associated(m) ! [1]
Allocate(n(5), stat=ial)
Select Case(ial)
Case(0)
Print *, "Allocation successful."
Case Default
Stop "Allocation failed."
End Select
m => n
n = -1
Print *, "Is pointer associated?", Associated(m)
DeAllocate(n, stat=ial)
Select Case(ial)
Case(0)
Print *, "DeAllocation successful."
Case Default
Stop "DeAllocation failed."
End Select
Print *, "Is pointer associated?", Associated(m) ! [2]
Print *, Size(m) ! [3]
Associate(p => m)
j = p(1)
print *, j
End Associate
End Program Test_UndefinedPointers
Abhi
I would like to know in what situations /check:pointer will help trap mistakes. The tooltip says that it will catch disassociated or uninitialized pointers and allocatable arrays. Does it mean "undefined" pointers by any chance?
For example, in the snippet below, the pointer m's status at [1] is undefined since it is not NULL-initialized while at [2] it is undefined because the target has been deallocated.
/check:pointer does not catch this. Is it expected to? Also, the associate contruct at [3] is also illegal.
{As far as I know, I don't think the standard specifies anything that compiler should do and one can expect unexpected results. I am wondering, however, if there is a way.}
===========
Program Test_UndefinedPointers
Implicit None
Integer, Allocatable :: n(:)
Integer :: ial, j
Integer, Pointer :: m(:) !=> Null()
Target :: n
!Nullify(m)
Print *, "Is pointer associated?", Associated(m) ! [1]
Allocate(n(5), stat=ial)
Select Case(ial)
Case(0)
Print *, "Allocation successful."
Case Default
Stop "Allocation failed."
End Select
m => n
n = -1
Print *, "Is pointer associated?", Associated(m)
DeAllocate(n, stat=ial)
Select Case(ial)
Case(0)
Print *, "DeAllocation successful."
Case Default
Stop "DeAllocation failed."
End Select
Print *, "Is pointer associated?", Associated(m) ! [2]
Print *, Size(m) ! [3]
Associate(p => m)
j = p(1)
print *, j
End Associate
End Program Test_UndefinedPointers
Abhi
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/check:pointer gives you a run-time error when you are trying to access the data through an unallocated pointer. Use of ASSOCIATED would never trigger this, though it is an error to use ASSOCIATED on a pointer whose association status is undefined.
In the case of [3], the association status of m is undefined because the data it points to has been deallocated, but that's a "dangling pointer" which Intel Fortran cannot detect. It's possible that in the future, when Intel Parallel Inspector supports Fortran, this sort of thing will be detectable.
In the case of [3], the association status of m is undefined because the data it points to has been deallocated, but that's a "dangling pointer" which Intel Fortran cannot detect. It's possible that in the future, when Intel Parallel Inspector supports Fortran, this sort of thing will be detectable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Many thanks, Steve.
At [3] (i.e. before associated querry) I also had Size querring the size of m. I guess that is also not covered by /check:pointers.
I acknowledge it's bit silly to ask but will it be possible to give an example of cases of diassociated/uninitialized pointers and allocatable arrays that are caught by /check:pointer?
Sincerely
Abhi
At [3] (i.e. before associated querry) I also had Size querring the size of m. I guess that is also not covered by /check:pointers.
I acknowledge it's bit silly to ask but will it be possible to give an example of cases of diassociated/uninitialized pointers and allocatable arrays that are caught by /check:pointer?
Sincerely
Abhi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
E:\Projects>type t.f90
real, allocatable :: x(:)
print *, x(3)
end
E:\Projects>ifort /check:pointer t.f90
Intel Visual Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100203 Package ID: w_cprof_p_11.1.060
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
Microsoft Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
-out:t.exe
-subsystem:console
t.obj
E:\Projects>t.exe
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable X when it is not allocated
Image PC Routine Line Source
t.exe 0000000140051E88 Unknown Unknown Unknown
t.exe 000000014004CF69 Unknown Unknown Unknown
t.exe 00000001400165AD Unknown Unknown Unknown
t.exe 0000000140009667 Unknown Unknown Unknown
t.exe 00000001400099D5 Unknown Unknown Unknown
t.exe 00000001400010D3 Unknown Unknown Unknown
t.exe 000000014005406C Unknown Unknown Unknown
t.exe 000000014003BDBF Unknown Unknown Unknown
kernel32.dll 0000000076C9F56D Unknown Unknown Unknown
ntdll.dll 0000000076ED3281 Unknown Unknown Unknown
E:\Projects>
real, allocatable :: x(:)
print *, x(3)
end
E:\Projects>ifort /check:pointer t.f90
Intel Visual Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100203 Package ID: w_cprof_p_11.1.060
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
Microsoft Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
-out:t.exe
-subsystem:console
t.obj
E:\Projects>t.exe
forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable X when it is not allocated
Image PC Routine Line Source
t.exe 0000000140051E88 Unknown Unknown Unknown
t.exe 000000014004CF69 Unknown Unknown Unknown
t.exe 00000001400165AD Unknown Unknown Unknown
t.exe 0000000140009667 Unknown Unknown Unknown
t.exe 00000001400099D5 Unknown Unknown Unknown
t.exe 00000001400010D3 Unknown Unknown Unknown
t.exe 000000014005406C Unknown Unknown Unknown
t.exe 000000014003BDBF Unknown Unknown Unknown
kernel32.dll 0000000076C9F56D Unknown Unknown Unknown
ntdll.dll 0000000076ED3281 Unknown Unknown Unknown
E:\Projects>
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page