Memory fault copying allocated array in custom type (Fortran 2003 feature)

[enyalius]

Hi all,

What do you make of the following code test-case? On a RHEL5 setup here compiling this code with ifort (tested with 10.1.022 for AMD64 Linux and with 11.1.038 for AMD64 Linux) results in a memory fault at line 22 (during the array copy). Code executes fine with gfortran 4.2+ and Sun Studio 12. Someone on #fortran@freenode.net tested ifort 11.0 and 11.1 and got no segfault running the testcase but reported that valgrind showed some errors:
==25534== Invalid write of size 4
==25534== at 0x40310E: mytype_module_mp_copy_mytype_ (fhjff.f90:22)
==25534== by 0x4036B2: MAIN__ (fhjff.f90:41)

Is this a bug in the Intel compiler or a problem in the code? Note that doing the array copy in a do or forall statement one 'k' slice at a time seems to work around the bug. Also reducing the size of the array significantly works too.

testcase:

[cpp]module mytype_module
  type mytype
    real, dimension(:, :, :), allocatable :: values
  end type mytype

  contains

  Function copy_mytype(a)  result(b)
    Implicit None

    type(mytype), intent(in) :: a
    type(mytype)  :: b
    integer :: Ni, Nj, Nk

    Ni = size(a%values, 1)
    Nj = size(a%values, 2)
    Nk = size(a%values, 3)
   
    allocate(b%values(Ni, Nj, Nk))

    write (*,*) 'about to copy values '
    b%values = a%values
    write (*,*) 'copy done'
  end function copy_mytype

end module mytype_module

program test_mytype
    use mytype_module
    Implicit None

    type(mytype) :: a, b
    integer :: Ni, Nj, Nk
    Ni = 500
    Nj = 500
    Nk = 50

    allocate(a%values(Ni, Nj, Nk))
    a%values = 1.

    b = copy_mytype(a)

    write (*,*) 'done'
end program

[/cpp]

[enyalius]

Seems like the -heap-arrays compiler option fixes it for me. I should have read the guide at http://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors/ earlier!

I'll have to do more research about how ifort uses stack...

[Steven_L_Intel1]

The compiler could do a better job at realizing that no temporary array was needed in this case. It is something we hope to improve in the future.