coarray problem with allocatable array and derived types

[John_D_6]

Hi,

I added some code which either segfaults or prints the wrong result (ifort 15.0.2, Intel MPI 4.1.3.049). It should work, as far as I understand the standard, so I'm assuming that it's a compiler bug.

Any help is appreciated,

John

[pbkenned1]

Looks like a straight bug.  Let me investigate a bit more and then I'll report to the developers.

Patrick

[pbkenned1]

The problems have been reported to the developers.  I'll keep this thread updated with any news.

Internal tracking ID: DPD200366587

Patrick

[John_D_6]

Hi Patrick,

thanks for picking this up.

I have a slightly different, but maybe related, problem when copying derived types:

program coarraybug
implicit none

  type b
    real,allocatable,dimension(:) :: c
  end type

  type(b),codimension
 :: v
  integer image

  image=this_image()
  allocate(v%c(2))
  v%c=image
  print*,'image,v=',image,v
  sync all
  if (image.eq.2) then
    v=v[1]
    print*,'v=',v
  endif

end

this program segfaults when trying to copy the coarray of derived type with an allocatable inside.

[John_D_6]

Hi,

could I get a confirmation that the second example is also being looked at? Otherwise, I'll create a new forum topic.

[pbkenned1]

I'll look at it when I can find the time.  In future please log a new forum issue for something new.  We can only attach one developer problem report to a given thread, and DPD200366587 is attached to this one. 

Patrick

[John_D_6]

Hi Patrick,

thanks for your reply. I'll create a new topic next time.

[pbkenned1]

Hi John,

Thanks for your understanding.  By keeping a one-to-one correspondence between forum threads and developer problem reports, it's much easier for us to properly track and resolve issues.  Otherwise, new issues reported in old threads can get lost, might not be noticed, etc.  That said, it's just our bookkeeping issue and we do appreciate bug reports, however reported.

I couldn't reproduce the access violation on Windows, but the image 2 copy of image 1 data is incorrect, so I reported this new bug to the developers as well (internal tracking ID DPD200366692).

Thanks,

Patrick

C:\ISN_Forums\U541619\Problem2>ifort -Qcoarray bug2.f90 -traceback
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.179 Build 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:bug2.exe
-subsystem:console
-incremental:no
bug2.obj

C:\ISN_Forums\U541619\Problem2>bug2.exe
 image,v=           2   2.000000       2.000000
 v=  0.0000000E+00  0.0000000E+00
 image,v=           1   1.000000       1.000000
 image,v=           3   3.000000       3.000000
 image,v=           4   4.000000       4.000000

[pbkenned1]

The original problem reported (test case bug.f90, internal tracking ID DPD200366587) exposed two problems -- one is a compiler defect, the other a user error.  Consider this code snippet from bug.f90:

  image=this_image()

! if the array is allocated on both images, the result is incorrect
!  allocate(CacheFields%lli%lon_deg(10))
  if (image.eq.1) then
! if the array is only allocated on image 1, the code crashes
    allocate(CacheFields%lli%lon_deg(10))

Notice that the first allocate() is commented out.  If you uncomment it, indeed the image 2 result is incorrect:

[U541619]$ ./bug.f90-ifort.x
 CacheFields%lli%lon_deg(1)=  -177.0000
 CacheFields[1]%lli%lon_deg(1)=  -177.0000
  allocated(CacheFields%lli%lon_deg) was TRUE
  this is image 2
 CacheFields[1]%lli%lon_deg(1)=   98.00000     ; should be -177.0000
[U541619]$
 

This is the compiler defect, and the developers have targeted the fix for the 16.0 compiler.

The user error relates to this sub-snippet:

 if (image.eq.1) then
! if the array is only allocated on image 1, the code crashes
    allocate(CacheFields%lli%lon_deg(10))

The is illegal - if an allocate is done of a coarray in one image, it must be done the same way in all images.

Per the F2008 standard, section 6.7.1.2, paragraph 4:

'When an ALLOCATE statement is executed for which an allocate-object is a coarray, there is an implicit synchronization of all images. On each image, execution of the segment (8.5.2) following the statement is delayed until all other images have executed the same statement the same number of times.'

Patrick

[John_D_6]

Hi Patrick,

it's excellent to hear that this will be fixed in release 16.

About the user error: I think that the code is correct. I'm not allocating a coarray, but I'm allocating an allocatable component of a derived type coarray. That should be possible independently on every image (and I expect without synchronization), even with varying sizes per image. I can't find an explicit mention of this in the standard, but note 6.18 in section 6.7.1.1 seems to come close. Of course, the Fortran standard is long and quite terse..

[pbkenned1]

The defect reported via DPD200366587 is now fixed in the 16.0 compiler, so I am closing this ticket now.  Sorry I don't have any feedback from the developers regarding your claim there is no coding error.  The F'2008 spec. is a bit fuzzy here.

Thanks,

Patrick

[U541619]$ ifort -V

Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.109 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

[U541619]$ ifort -fpp -coarray -coarray-num-images=2 bug.f90 -o bug.f90-ifort.x
[U541619]$ ./bug.f90-ifort.x
 CacheFields%lli%lon_deg(1)=  -177.0000
 CacheFields[1]%lli%lon_deg(1)=  -177.0000
  allocated(CacheFields%lli%lon_deg) was TRUE
  this is image 2
 CacheFields[1]%lli%lon_deg(1)=  -177.0000     ; should be -177.0000
[U541619]$