Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

internal compiler error

Roman1
New Contributor I
621 Views

I am using Intel(R) Visual Fortran Compiler 16.0.1.146.  When I compile the following sample program, the compiler crashes with:

fortcom: Fatal: There has been an internal compiler error (C0000005).

The following compiler options are set:

ifort /nologo /debug:full /Od /heap-arrays0 /Qopenmp /stand:f08 /warn:all /Qtrapuv /Qinit:snan /Qinit:arrays /fpe:0 /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc100.pdb" /traceback /check:all /libs:static /threads /dbglibs /c /Qvc10

module mymod2

   type mytype
      real,allocatable:: w(:)
   end type mytype

   interface operator(*)
      module procedure vectormult
   end interface

   contains

   function vectormult( a, b )  result(c)
   implicit none
   type(mytype),intent(in):: a
   real,intent(in):: b(:)
   real,allocatable:: c(:)
   integer i, n
   
   n = size(b)
   
   allocate( c(n) )
   do i = 1, n
      c(i) = a%w(i) * b(i)
   end do
   return
   end function vectormult
   
   
end module mymod2

!------------------------------------------------
   
module mymod
contains

   subroutine mysub()
   use mymod2, only: mytype, operator(*)
   implicit none

   integer i, m,n
   real,allocatable:: a(:,:)
   real,allocatable:: z(:)
   type(mytype)::  x, y

   m = 100
   n = 10
   allocate(a(n,m))
   allocate( x%w(n), y%w(n), z(n)  )
   x%w = 1.0 ; y%w = 1.0 
   z = 1.0
   
   !$OMP parallel default(shared), private(i)
   !$OMP do schedule(dynamic)
   do i = 1, m
      a(:,i) = x * (y * z)
   end do
   !$OMP end do
   !$OMP end parallel

   return
   end subroutine mysub
end module mymod

!------------------------------------------------

program test_ice

use mymod, only: mysub
implicit none

call mysub()

stop
end program test_ice

 

0 Kudos
5 Replies
Steven_L_Intel1
Employee
621 Views

Thanks, I'll look into this on Monday.

0 Kudos
Andrew_Smith
Valued Contributor I
621 Views

This workaround compiles OK:

      !$OMP parallel default(shared)
      !$OMP single
      do i = 1, m
         !$OMP task firstprivate(i)
         a(:,i) = x * (y * z)
         !$OMP end task
      end do
      !$OMP end single
      !$OMP end parallel

It should work in your example but might need a taskwait in larger code.

Since the amount of work in each iteration is the same then your original code (if it compiled) would probably be faster than using tasks and should not need the dynamic schedule.

You might also consider using an automatic size for the return argument C of the function so that it gets allocated on stack instead of heap. That is usually faster in parrallel environment but in the context of a function return, I am not sure.

 

 

0 Kudos
Steven_L_Intel1
Employee
621 Views

This looks an awful lot like our issue DPD200377155, which should get fixed in Update 2 (February). I tried the program with the current development stream and it built successfully. The combination of /Qopenmp and /heap-arrays is needed to see the bug.

You can either turn off /heap-arrays or try Andrew's suggestion. The bug has to do with making private copies of array "dope vectors" in parallel regions. I am going to add your test case to the existing bug report just to be sure.

0 Kudos
Roman1
New Contributor I
621 Views

Thanks for looking at this.  I checked, and disabling /heap-arrays makes the code compile.

While experimenting, I noticed something strange.  If /heap-arrays is enabled, the code compiles if I change line 56 from:

a(:,i) = x * (y * z)

to:

a(:,i) = vectormult(x, vectormult(y, z))

Aren't the above two lines do the same thing, since operator(*) calls vectormult ?

 

0 Kudos
Steven_L_Intel1
Employee
621 Views

One would certainly think so. I am not sure why there is a difference.

0 Kudos
Reply