Attached is a simple test case that crashes on a complex matrix assign in ifort 16.0.3. It works with all previous ifort versions I have used. The crash occurs when using the cmplx intrinsic and does not occur when not using the intrinsic. For example,
zz = cmplx(0._db,0._db,db) ! db defined in test file
zz = 0._db ! db defined in test file
does not. My compile line is
ifort -traceback testZ8.F90
This appears related to the creation of array stack temporaries. The program runs with pre-16.0 compilers without any aid and runs with 16.0 compilers with the aid of either -heap-arrays or elevating the shell stack limit (i.e. ulimit –s unlimited).
I need to consult others whether the changed behavior was anticipated with 16.0. I'll update after learning more.
For convenience I included your test case below.
!====================================================================== program test implicit none integer, parameter :: db = kind(1.0d0) integer, parameter :: sg = kind(1.0) integer, parameter :: stdout = 6 ! local variables integer :: itmp, i, ierr, m complex(db), allocatable :: zz(:,:) complex(sg), allocatable :: cc(:,:) m = 5868 allocate(zz(m,m),stat=ierr) write(stdout,*) 'IERR: ', ierr allocate(cc(m,m),stat=ierr) write(stdout,*) 'IERR: ', ierr zz = 0._db ! This line ok zz = cmplx(0._db,0._db,db) ! This line crashes cc = 0._sg ! This line ok cc = cmplx(0._sg,0._sg,sg) ! This line crashes deallocate(zz,cc) end program test
In version 15, the compiler did a simple element-by-element initialization in a loop. In version 16 it created an array temp for the whole initialized array and copied it - this triggered the stack overflow. In the upcoming version 17, it generates a vectorized loop to more efficiently set the values and doesn't use a temp.