Deallocated pointers still have old shape specifications

[Gus_Hart]

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

[Kevin_D_Intel]

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 )

[Steven_L_Intel1]

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.

[Gus_Hart]

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.

[Kevin_D_Intel]

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.