Wrong ASSOCIATED behavior?

[Daniel_Dopico]

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?

[jimdempseyatthecove]

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

[Steve_Lionel · Accepted solution]

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.

[Daniel_Dopico]

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.

[Daniel_Dopico]

I have just put a ticket on this.

Thanks.

[jimdempseyatthecove]

Steve, aren't pointers that cannot be associated by definition .NOT. associated?

Jim Dempsey

[Steve_Lionel]

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.

[Ron_Green]

This bug was fixed in PSXE 2020 Update 2, compiler 19.1.2