There may be polymorphic whiz-jiggery going on that is confusing me, but something doesn't seem right with associated when applied to polymorphic pointer dummy arguments.
PROGRAM associate_is_disassociated_from_reality IMPLICIT NONE TYPE :: Parent ! Comment me out for some access violation fun. INTEGER :: just_so_im_not_zero_sized END TYPE Parent CLASS(Parent), POINTER :: p !**** ALLOCATE(p) CALL proc(p) DEALLOCATE(p) CONTAINS SUBROUTINE proc(ptr) CLASS(Parent), INTENT(IN), POINTER :: ptr CLASS(Parent), POINTER :: a !**** ! T and F below assume component is still part of the type. PRINT *, ASSOCIATED(ptr) ! T - Ok. PRINT *, ASSOCIATED(ptr, ptr) ! F - Not Ok. PRINT *, ASSOCIATED(p, ptr) ! T - Ok. PRINT *, ASSOCIATED(ptr, p) ! F - Not Ok. a => ptr PRINT *, ASSOCIATED(a, ptr) ! T - Ok. PRINT *, ASSOCIATED(ptr, a) ! F - Not Ok. END SUBROUTINE proc END PROGRAM associate_is_disassociated_from_reality
>ifort /check:all /warn:all /standard-semantics "2014-04-28 simple.f90" & "2014-04-28 simple.exe" Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 220.127.116.11 Build 20140130 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. "-out:2014-04-28 simple.exe" -subsystem:console "2014-04-28 simple.obj" T F T F T F
Comment out the component in the type and any of the associated intrinsics that reference the ptr thing as the POINTER argument of the ASSOCIATED intrinsic start exploding (noting that the rules around zero sized sequences change the results that should be expected, and noting that I'm noting that because I'm always excited when I learn something new).