I think there are essentially two problems possible with pointers: (a) Uninitialized pointer (i.e. neither NULL nor associated) (b) Using an unassociated pointer I think checking (a) is not easily doable as one would need to pass this status (has been initialized? yes/no) on to subroutines. (NAG f95 does so, but one needs to compile all parts of the program with this option as the variable status is passed on to the subroutines. This -C=uninitialized options is still great to find uninitialized variables, esp. those (e.g. integer) which can not be pre-autoinitialized by NaN.) Thus this is a request for enhancement for the second type. Example: program pointtest implicit none real, pointer :: r nullify(r) call foo(r) ! Error one r = 5.0 ! Error two contains subroutine foo(bar) real, target, intent(in) :: bar ! The error occures already here and not in the next line! print *, bar end subroutine foo end program pointtest Both are caught by NAG f95 with -C=pointer and by ifort with -check pointer: Reference to disassociated POINTER R and forrtl: severe (408): fort: (7): Attempt to use pointer R when it is not associated with a target However, the error analysis could be improved for both: Ifort gives a trace, but even with "-g" it does not show where. NAG at least coredumps and thus one can find out where it crashes: gdb -> bt ... #3 0x00002af4962e5e1a in __NAGf90_badptr1 () from /opt/nag/lib/libf98.so.1 #4 0x0000000000403338 in main (argc=1, argv=0x7fff14a00578) at pointest.f90:6 We should try to find something, which is easily debuggable (e.g. spitting out the file and line number?). If we say that the user should use gdb himself [as we used to with boundary check], then we should at least tell, were to set the break point [unless we coredump, the one can use "bt"]. At least I didn't found it obvious to set a break point at "exit__" (or something like that), which was also in a library not loaded when loading the program in gdb. Well, fortunally -fbounds-check now prints file and line :-) (The two pointer tests of Polyhedron's diagnotic check, by the way, only the first type.)
Besides pointers, the same is also true for deallocated variables, only that the unknown state does not exist. (Idea taken from 31318) > I think there are essentially two problems possible with pointers: > (a) Uninitialized pointer (i.e. neither NULL nor associated) > (b) Using an unassociated pointer > I think checking (a) is not easily doable as one would need to pass this > status (has been initialized? yes/no) on to subroutines. (a) should be possible if one restricts oneself to restricts oneself to local variables. If they are passed as actual argument to non-pointer (or non-allocatable) dummies, this is also an error. For allocatable variables the checking is always possible.
*** Bug 31318 has been marked as a duplicate of this bug. ***
PR 40580 added an argument checking for pointer/proc-pointer/allocatable, i.e. the example "call foo(r)" of comment 0 is now detected via -fcheck=pointer. TODO: a) call sub( uninit_alloc_returning_function() ) does not work as the _gfortran_internal_pack comes too early, see comment in gfortran.dg/pointer_check_5.f90 b) Assignments are not checked, e.g. r = 5.0 (see comment 0) c) One can add checks for uninitialized pointers - by automatically initializing them to a special value - and checking for that value. d) There are still issues with proc-pointer returning functions; tracked at PR 40593
PR 39230 is connected to item (c) in comment #3.
Compiling the test in comment 0 with -fcheck=all gives At line 5 of file pr29616.f90 Fortran runtime error: Pointer actual argument 'r' is not associated since at least 4.8.