Solved: Why reshape gives me ‘insufficient virtual memory’ error? - Page 2

CRquantum · ‎09-15-2021

I have an extremely simple Fortran code,

program main
integer, parameter :: i4=selected_int_kind(9)
integer, parameter :: i8=selected_int_kind(15)
integer, parameter :: r8=selected_real_kind(15,9)
integer(kind=i8) :: np
np = 2
call test03(np)
stop
end
subroutine test03(n)
integer, parameter :: i4=selected_int_kind(9)
integer, parameter :: i8=selected_int_kind(15)
integer, parameter :: r8=selected_real_kind(15,9)
integer ( kind = i8 ), intent(in) :: n
real ( kind = r8 ) :: warray(n,4),normal(n,4)
warray = 1.0
write(6,*) 'reshape', reshape(warray,shape(warray))
return
end subroutine test03

I use Intel OneAPI + visual studio 2015/2017.
Problem is, if I compile with intel Fortran in 'release mode' with options /O3 /QxHost /traceback

When I run it, it just give me ''insufficient virtual memory' error below,

in 'debug' mode it also have this error.

Does anyone know why?

However, in 'release' mode, if I enable the below options setting default integer and real as kind 8, it works fine again.

Thank you very much in advance!

Steve_Lionel · ‎09-17-2021

Thanks. I CAN reproduce this, but only when building for x64. Your project has a bunch of other options set, such as /Qmkl:cluster and /QxHost, but they don't matter. Only /heap-arrays matters, and I can reproduce it in a debug configuration as well (so it isn't optimization related).

I don't know the argument list for for_allocate (the run-time library routine that does dynamic allocation), but it looks to me as a second for_allocate in that WRITE has a size of 262144 (piddling) and gets the error. The first one in that statement has the same size, no error.

Some more observations. If I move the reshape out of the WRITE and execute it on its own statement, assigning to a second array, I still get the error. But if I replace "shape(warray)" with [2,4], which should be the same, it works. So there is something rotten going on with shape(warray).

I must be misinterpreting the argument to for_allocate, as the array size should be 64, not 262144....

A workaround is to have a local two-element integer array into which you assign shape(warray) and then use that as the argument to reshape. For example:

    subroutine test03(n)
    implicit none
    integer, parameter :: i4=selected_int_kind(9)
    integer, parameter :: i8=selected_int_kind(15)
    integer, parameter :: r8=selected_real_kind(15,9)
    integer ( kind = i8 ), intent(in) :: n
    real ( kind = r8 ) :: warray(n,4)
    integer :: wshape(2)
    warray = 1.0
    wshape = shape(warray)
    write(6,*) 'reshape03', reshape(warray,wshape)
    return
    end subroutine test03

In any case, this looks like a compiler bug. If you have support, please open a ticket at the Intel Online Service Center. Otherwise let's hope an Intel support person picks it up from here.

View solution in original post

CRquantum · ‎09-20-2021

Thank you very much indeed Dr. Fortran!

The example is really great!

Dr. Fortran, would you perhaps look at my another thread in this Forum? I managed to make MWE to 30 lines so very short.

Not sure if it is an intel compiler bug or not. But this problem only happens to intel Fortran, the same version, OneAPI 2021.3. Other intel version I do not know. gfortran works fine. Simply speaking -O2 or -O3 flags, result is wrong.

Thank you very much in advance!

https://community.intel.com/t5/Intel-Fortran-Compiler/O2-O3-gives-obvious-wrong-results-simple-30-lines-MWE-attached/td-p/1316062

jimdempseyatthecove · ‎09-21-2021

You may want to consider adding then CONTIGUOUS attribute to rank4_array as well. This may help with performance (but is not required for correctness).

Jim Dempsey

Steve_Lionel · ‎09-21-2021

I saw that post, but have nothing to add. I agree it looks like a compiler bug.

Steve_Lionel · ‎01-13-2023

Intel Support tells me that the originally reported problem is fixed in the latest compiler update (2023.0.0 with ifort 2021.8).

CRquantum · ‎01-14-2023

Thank you so much Dr. Fortran! Yeah, I have just tested, it looks like this issue has been fixed. Cool!

Have a nice day!

Best regards,

Rong

Igor_V_Intel · ‎02-01-2023

The bug is fixed in the latest compiler version.