------- Comment #2 from kargl at gcc dot gnu dot org 2009-08-20 05:59 -------
gfortran 4.5.0 gives
REMOVE:kargl[5] ./z
x0%P T
x0%P T
x1%P F
x1%P T
Given that you are using a f95 compiler, I believe that you are
invoking processor-dependent behavior. F95 states
2.4.6 Pointer
A pointer is a variable that has the POINTER attribute. A pointer
is associated with a target by allocation (6.3.1) or pointer assignment
(7.5.2). A pointer shall neither be referenced nor defined until it is
associated.
You're first use of ASSOCIATED references a pointer that has not been
associated with a target or through allocation. Further, in Section
4.4.1 it states
A component is a pointer if its component-attr-spec-list contains
the POINTER attribute. Pointers have an association status of
associated, disassociated, or undefined. If no default initialization
is specified, the initial status is undefined.
Your derived types do not use default initialization. Finally, one finds
13.14.13 ASSOCIATED (POINTER [, TARGET])
Description. Returns the association status of its pointer argument
or indicates the pointer is associated with the target.
Class. Inquiry function.
Arguments.
POINTER shall be a pointer and may be of any type.
Its pointer association status shall not be undefined.
Thus, I think gfortran is giving an acceptable answer.
PS: gfortran bugs are never have a severity of critical.
PPS: I'll let someone else determine if my analysis is correct. I've
been known to read the standard with a fairly strict interpretation.
PPPS: Fortran 2003 has different restriction on ASSOCIATED and pointers.
I'm too lazy at the moment to look up the differences.
PPPPS: You really want to update from version 4.1.2 to at least a 4.4.x
version.
--
kargl at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41129
