Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Use of /check:pointer

abhimodak
New Contributor I
716 Views
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
0 Kudos
3 Replies
Steven_L_Intel1
Employee
716 Views
/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.
0 Kudos
intelsupport1
Beginner
716 Views
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
0 Kudos
Steven_L_Intel1
Employee
716 Views
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>
0 Kudos
Reply