topic I'll look at it when I can in Intel® Fortran Compiler

coarray problem with allocatable array and derived types

John_D_6 — Tue, 17 Feb 2015 12:43:19 GMT

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

Looks like a straight bug.

pbkenned1 — Tue, 17 Feb 2015 17:05:15 GMT

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

Patrick

The problems have been

pbkenned1 — Tue, 17 Feb 2015 21:28:44 GMT

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

Internal tracking ID: DPD200366587

Patrick

Hi Patrick,

John_D_6 — Wed, 18 Feb 2015 12:44:22 GMT

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.

Hi,

John_D_6 — Thu, 19 Feb 2015 06:54:32 GMT

Hi,

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

I'll look at it when I can

pbkenned1 — Thu, 19 Feb 2015 12:39:19 GMT

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

Hi Patrick,

John_D_6 — Thu, 19 Feb 2015 14:28:56 GMT

Hi Patrick,

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

Hi John,

pbkenned1 — Thu, 19 Feb 2015 15:04:00 GMT

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.

-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

The original problem reported

pbkenned1 — Fri, 22 May 2015 19:01:06 GMT

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

Hi Patrick,

John_D_6 — Fri, 22 May 2015 20:40:00 GMT

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..

The defect reported via

pbkenned1 — Tue, 27 Oct 2015 16:44:29 GMT

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

[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]$