This code compiles on Intel Fortran 2019, but according to the standard it should not.
PROGRAM isASSOCIATED
IMPLICIT NONE
TYPE PUNTO
INTEGER idpt
REAL(8),DIMENSION(3)::pt_loc
END TYPE PUNTO
TYPE VECTOR
INTEGER idpt
REAL(8),DIMENSION(3)::vc_loc
END TYPE VECTOR
TYPE(PUNTO),POINTER::pt
TYPE(VECTOR),TARGET::vc
IF(ASSOCIATED(pt,vc)) THEN
PRINT *,"Pointer associated with target"
ELSE
PRINT *,"Pointer not associated with target"
ENDIF
END PROGRAM isASSOCIATED
The output of the program is of course the message "Pointer not associated with target", but there is no way that the pointer can be associated with the target because they have different types.
The standard says about the ASSOCIATED(pointer,[target]) that the target must have the same type as the pointer, nevertheless the Intel fortran documentation doesn't mention it. Is this an extension of Intel for some reason?
It's just a failure to check the types - I very much doubt it is a deliberate extension.
The standard doesn't say "the target must have the same type". What it says is:
TARGET (optional) shall be allowable as the data-target or proc-target in a pointer assignment statement (10.2.2) in which POINTER is data-pointer-object or proc-pointer-object.
Nonetheless, it is evident that the use here is not conforming, as if you add:
pt => vc
the compiler complains:
error #6795: The target must be of the same type and kind type parameters as the pointer. [PT]
pt => vc
----^
Enabling standards checking doesn't complain about the ASSOCIATED. In other words, it's simply an omission, or a bug if you prefer. I suggest reporting this through the Online Service Portal.
P.S. It would be a favor if an Intel person would edit the title to say ASSOCIATED rather than ASSOCIATE, which is something entirely different.
链接已复制
My read is for the pointers to be associated they must be of the same type .AND. both pointing to the same location.
For the pointers to .NOT. be associated, one or both may be null .OR. both non-null pointing elsewhere. As to if a compiler error is to be generated, I am not sure as to if this behavior is "undefined".
It would be interesting to know the behavior of two different type pointers, initialized with C_F_POINTER to the same location (or overlapping locations).
Jim Dempsey
It's just a failure to check the types - I very much doubt it is a deliberate extension.
The standard doesn't say "the target must have the same type". What it says is:
TARGET (optional) shall be allowable as the data-target or proc-target in a pointer assignment statement (10.2.2) in which POINTER is data-pointer-object or proc-pointer-object.
Nonetheless, it is evident that the use here is not conforming, as if you add:
pt => vc
the compiler complains:
error #6795: The target must be of the same type and kind type parameters as the pointer. [PT]
pt => vc
----^
Enabling standards checking doesn't complain about the ASSOCIATED. In other words, it's simply an omission, or a bug if you prefer. I suggest reporting this through the Online Service Portal.
P.S. It would be a favor if an Intel person would edit the title to say ASSOCIATED rather than ASSOCIATE, which is something entirely different.
Thank you Steve. Sorry for the typo in the topic title: as you said the ASSOCIATE construct is something completely different.
For me it is a bug too, but since the Intel documentation is not complete on this, I had doubts that this could be done on purpose (nevertheless if i am right a green color should be used for any intended extensión and this is not the case).
It would be welcome if they correct the bug and the documentation. I paste the documentation on the target here:
target (Input; optional) Must be a pointer or target. If it is a pointer, the pointer association status must be defined.
I thik it should be advised that the target should be "pointable" by the pointer, as you said, otherwise a compiler error would be obtained.
I have just put a ticket on this.
Thanks.
Steve, aren't pointers that cannot be associated by definition .NOT. associated?
Jim Dempsey
Jim, I don't understand your question,. Any given pointer CAN be associated, with an allowed target. The issue here in ASSOCIATED is that the standard requires that TARGET be allowed as a pointer target for POINTER, which it isn't in this example. The proper behavior is a compile-time error similar to the one I show in #3. I could certainly modify the example to associate pt with something else.
