Strange coarray behavior

[OP1]

It seems that the following code produces all kinds of weird, non-repeatable results. The code was compiled with 16.0 and run in debug (x64) mode, while 'Enable F2003 Semantics' was set to either yes or no.

When 'Enable F2003 Semantics' is set to 'no' (which should, I believe, lead to an error on line 9), no error is encountered at all.

When 'Enable F2003 Semantics' is set to 'yes', results are non-repeatable (access violations, or array on image 1 showing only 0s, etc.)

PROGRAM TEST
IMPLICIT NONE
TYPE T
    INTEGER,ALLOCATABLE :: A(:)
    CHARACTER(LEN=2) :: S
END TYPE T
TYPE(T) :: U

IF (THIS_IMAGE()==2) THEN
    U%A = [1,2,3]
    U%S = 'AB'
    WRITE(*,*) U
END IF
SYNC ALL
IF (THIS_IMAGE()==1) THEN
    WRITE(*,*) SIZE(U[2]%A)
    U = U[2]
    WRITE(*,*) U
END IF
END PROGRAM TEST

[Steven_L_Intel1]

Thanks - we'll check it out.

[Steven_L_Intel1]

I can reproduce this.

The reason that you get no error without /standard-semantics is that, in this particular case, the compiler chose to do the assignment to U%A in image 2 using the current size of U%A, which happened to be zero. If you also enable /check:pointer, you'd get an error at that point.

The actual problem is the assignment to U in image 1. For the derived type assignment, it should be doing the automatic reallocation whether or not /standard-semantics is used, but obviously something goes wrong here. I find that if I assign to the individual components of U in the image 1 code, it works fine. It also works if I preallocate U%A.

Escalated as issue DPD200380443. Thanks for the nice example.

[OP1]

Just out of curiosity, I tried with 16 update 1, 2 and 3 - as well as 17 Beta, and the results are still the same: replication of derived type objects which are components of coarrays (which I think is a fairly essential feature to ease the passing of information/data across images) fails in all cases.
 

[Steven_L_Intel1]

Sorry, no news to report on this one. I have asked the developers for an update.