Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
1 View

Allocatable component of a coarray + MOVE_ALLOC bug

Note: subject title edited to reflect more accurately the condition below.

See example attached - run with 12 images. Image 1 gets 'stuck'. Switching the declaration of A from coarray to regular array highlights the difference in behavior... This is with 16 Update 3 and 17 Beta.

Sigh... how many of these are still left with coarrays :'(

PROGRAM MAIN
IMPLICIT NONE
TYPE T
    INTEGER(KIND=8),ALLOCATABLE :: U(:)
END TYPE T
TYPE(T) :: A
  • !TYPE(T) :: A ! This would work. INTEGER(KIND=8) :: I INTEGER(KIND=8),ALLOCATABLE :: TEMP(:) IF (THIS_IMAGE()==1) THEN DO I=1,2 IF (.NOT.ALLOCATED(A%U)) THEN ALLOCATE(A%U(1)) ELSE IF (ALLOCATED(TEMP)) DEALLOCATE(TEMP) ALLOCATE(TEMP(SIZE(A%U)+1)) TEMP(1:SIZE(A%U)) = A%U TEMP(SIZE(A%U)+1) = I CALL MOVE_ALLOC(TEMP,A%U) END IF END DO END IF WRITE(*,'(A,I0,A)') 'I am image ',THIS_IMAGE(),' and I am out of here!' SYNC ALL END PROGRAM MAIN
  •  

    0 Kudos
    2 Replies
    Highlighted
    1 View

    I can reproduce this with

    I can reproduce this with four images. At first I was hung up on what happens when coarrays get allocated an dellocated, but your program isn't doing that. I will send this on to the developers, issue ID DPD200411068.

    Along the way, I noticed that F2008 doesn't discuss coarrays at all in the context of MOVE_ALLOC, whereas the F2015 draft does.

    Retired 12/31/2016
    0 Kudos
    Highlighted
    1 View

    This bug will be fixed for

    This bug will be fixed for the final 17.0 product release. The compiler was confused as to whether it was dealing with a coarray and added synchronization code it shouldn't have.

    Retired 12/31/2016
    0 Kudos