coarray catastrophic error when broadcast element of allocatable array inside of user-defined type

[Zuodong_Y_]

Following code cause 010101_14291 catastrophic error on Intel(R) 64, Version 18.0.1.163 Build 20171018

program main
	implicit none
	type t_a
		integer, allocatable :: a(:,:)
	end type
	integer :: i,j
	type(t_a) :: self

	allocate(self%a(3,3))
	if(this_image()==1) then
		self%a=1
		do j=2,num_images()
			self%a(1:2,2)=self%a(1:2,2)
		enddo
	endif
end program

one can walk around this issue by changing a(1:2,2) to a(1:2,2:2). Can anyone help to check whether this issue remains on latest version? If yes, help to report to developer?  Thanks!

[Steve_Lionel]

Still fails in 19.0.5 and 19.1.

[FortranFan]

The catastrophic error looks like another strain of the dreaded "internal compiler error".  I suggest you submit a support request at Intel online servce center: https://supporttickets.intel.com/servicecenter?lang=en-US

Another workaround that may be of interest is element-by-element broadcast:

   type :: t
      integer, allocatable :: a(:,:)
   end type
   type(t), save :: foo

   integer :: j

   character(len=*), parameter :: fmtg = "(g0,t15,g0)"

   allocate ( foo%a(3,3) )
   foo%a = 0

   sync all

   if ( this_image() == 1 ) then
      foo%a(1:2,2) = 42
      do j = 2, num_images()
         do concurrent ( integer :: i = 1:2 )
            foo%a(i,2) = foo%a(i,2) + j - 1
         end do
      end do
   end if
   sync all

   if ( this_image() == 1 ) then
      print fmtg, "Image #", "foo%a(1:1,2)"
      do j = 1, num_images()
         print fmtg, j, foo%a(1:1,2)
      end do
   end if      
 
end

C:\Temp>ifort /standard-semantics /warn:all /stand:f18 /Qcoarray:shared /Qcoarray-num-images=8 p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.1.216 Build 20200306
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

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

-out:p.exe
-subsystem:console
p.obj

C:\Temp>p.exe
Image #       foo%a(1:1,2)
1             42
2             43
3             44
4             45
5             46
6             47
7             48
8             49

C:\Temp>

[Michael_S_17]

Fell free to correct me, but I’d rather think that your code could be the problem. How does it run if you did synchronize the ALLOCATE statement, like this using SYNC ALL:

program main
  implicit none
  type t_a
    integer, allocatable :: a(:,:)
  end type
  integer :: i,j
  type(t_a) :: self

  allocate(self%a(3,3))
  SYNC ALL
  if(this_image()==1) then
    self%a=1
    do j=2,num_images()
      self%a(1:2,2)=self%a(1:2,2)
    enddo
  endif
end program

Please notice that an allocatable component (of a derived type coarray) is itself NOT a coarray. Thus, the ALLOCATE statement that does allocate the component does NOT synchronize itself, -as it would if you would allocate a coarray-. Here, the ALLOCATE statement is NOT an image control statement, it is a purely local process.
The programming for such allocatable components does heavily differ from that of the encompassing derived type coarray because that component is usually not allocated on all images (of a coarray team). Instead, to establish a data transfer channel between images through an allocatable component, the programmer may allocate the component on a single image only. Sounds simple, but this does involve additional burden to the programmer, to track allocation status of such components and make the status remotely available through an additional non-allocatable component of the derived type coarray, as well as check the bounds of the allocated component remotely (intrinsic UBOUND and LBOUND do allow this remotely).
Internally, use of allocatable components for data transfer may require additional data transfer by the run-time to transfer memory addresses among images (see Modern Fortran explained, chapter 17.7.1).
Allocatable components (of derived type coarrays) are dangerous to use by programmers if they don’t understand the implications.

Best Regards

[Steve_Lionel]

Even if the code is wrong (and I have not evaluated that claim), an internal compiler error is always a compiler bug.

[Zuodong_Y_]

Good point. Thanks!

Michael S. wrote:

Fell free to correct me, but I’d rather think that your code could be the problem. How does it run if you did synchronize the ALLOCATE statement, like this using SYNC ALL:

program main
  implicit none
  type t_a
    integer, allocatable :: a(:,:)
  end type
  integer :: i,j
  type(t_a) :: self

  allocate(self%a(3,3))
  SYNC ALL
  if(this_image()==1) then
    self%a=1
    do j=2,num_images()
      self%a(1:2,2)=self%a(1:2,2)
    enddo
  endif
end program

Please notice that an allocatable component (of a derived type coarray) is itself NOT a coarray. Thus, the ALLOCATE statement that does allocate the component does NOT synchronize itself, -as it would if you would allocate a coarray-. Here, the ALLOCATE statement is NOT an image control statement, it is a purely local process.
The programming for such allocatable components does heavily differ from that of the encompassing derived type coarray because that component is usually not allocated on all images (of a coarray team). Instead, to establish a data transfer channel between images through an allocatable component, the programmer may allocate the component on a single image only. Sounds simple, but this does involve additional burden to the programmer, to track allocation status of such components and make the status remotely available through an additional non-allocatable component of the derived type coarray, as well as check the bounds of the allocated component remotely (intrinsic UBOUND and LBOUND do allow this remotely).
Internally, use of allocatable components for data transfer may require additional data transfer by the run-time to transfer memory addresses among images (see Modern Fortran explained, chapter 17.7.1).
Allocatable components (of derived type coarrays) are dangerous to use by programmers if they don’t understand the implications.

Best Regards

[Barbara_P_Intel]

I duplicated the ICE and filed a moth (bug) report your behalf, CMPLRIL0-32764. I'll let you know when a fix is available.

[JohnNichols]

The term ‘Computer Bug’ is coined by Grace Murray Hopper. During her work on Mark II and Mark III machine was facing some problem, later operators investigated and identified that there was a moth (Insect) trapped in a relay which was causing problem.

it should have been called a moth much prettier than a bug. 

[Zuodong_Y_]

Thanks a lot!

Barbara P (Intel) wrote:

I duplicated the ICE and filed a moth (bug) report your behalf, CMPLRIL0-32764. I'll let you know when a fix is available.

[Barbara_P_Intel]

I just compiled this without error using PSXE 2020 update 2 (ifort 19.1.2) that was released last week. Please try it!