Deallocated pointers still have old shape specifications

Deallocated pointers still have old shape specifications

I found it odd that deallocated pointers still have their shape information, even though "associated" returns .false. I suppose I expected to get an error, or at least zeroes. Is there a good reason for this behavior? Perhaps it makes sense but I can't see how.

program test_alloc
implicit none
integer, pointer :: perms(:,:)=>null()

print*,"associated",associated(perms)
print*,"shape",shape(perms)
allocate(perms(3,5))
print*,"associated",associated(perms)
print*,"shape",shape(perms)
deallocate(perms)
print*,"associated",associated(perms)
print*,"shape",shape(perms)
perms=>null()
print*,"associated",associated(perms)
print*,"shape",shape(perms)

end program test_alloc

 

 associated F
 shape           0           0
 associated T
 shape           3           5
 associated F
 shape           3           5
 associated F
 shape           3           5

 

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The Fortran 2008 standard states that for SHAPE(SOURCE[, KIND]), in section 13.7.149 line 17, for argument SOURCE "It shall not be an unallocated allocatable variable or a pointer that is not associated." It does seem there should be perhaps a run-time error produced.

I reported this to Development (see internal tracking id below) and will let you know what I hear back.

(Internal tracking id: DPD200359180 )

While an error might be nice, it isn't required by the standard. Basically the behavior is undefined in this circumstance as the program is non-conforming. It would probably be useful if enabling -check pointer gave an error here - it currently doesn't.

Steve - Intel Developer Support

Being able to add a flag to the compilation that would cause this to trigger an error would be useful.

One of my programs was triggering segfaults and I suspected an unallocated or deallocated array, so I started printing the shapes of the suspect arrays to see if I could find which one was the culprit. I suppose that was the wrong strategy and I'm "one mistake smarter now," but having the compiler catch stuff like this would be nice in any case.

 

Thank you for the clarification Steve. I submitted this to Development against the -check pointers option not detecting the use of the disassociated pointer for this case.

Leave a Comment

Please sign in to add a comment. Not a member? Join today