Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
137 Views

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

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!

    0 Kudos
    9 Replies
    Highlighted
    Black Belt Retired Employee
    137 Views

    Still fails in 19.0.5 and 19.1.

    0 Kudos
    Highlighted
    Honored Contributor I
    137 Views

    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>

     

    0 Kudos
    Highlighted
    Beginner
    137 Views

    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

    0 Kudos
    Highlighted
    Black Belt Retired Employee
    137 Views

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

    0 Kudos
    Highlighted
    Beginner
    137 Views

    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

    0 Kudos
    Highlighted
    Moderator
    137 Views

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

     

    0 Kudos
    Highlighted
    New Contributor II
    137 Views

    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. 

    0 Kudos
    Highlighted
    Beginner
    137 Views

    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.

     

    0 Kudos
    Highlighted
    Moderator
    118 Views

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



    0 Kudos