parameters as actual argument cause stack overflow

[An_N_1]

My old project goes wrong with Intel® Parallel Studio XE 2017 Update 4 again.

In sample code, subroutine foo crash on debug mode. (Stack overflow)

If change integer :: a(N) to a(1000000), the code goes well.

Similar things was happened with character parameter argument also.

    program Console2

        call foo(1000000)
    
    end program Console2
    
    subroutine foo(N)

    implicit none
    
    integer :: N
    
        integer:: a(N)
    
    end subroutine

[Arjen_Markus]

Do you have the option for debugging parameters on? (/debug-parameters:used or all). This has been the cause for similar crashes for me. It has been discussed before in this forum.

In Visual Studio the Debugging set of options

[An_N_1]

I have posted complier error by 'Information for PARAMETER Constants' set to All.

For this one, it doesn't matter.

[Arjen_Markus]

Oops, I should have mentioned that you should set the value to "none". You cannot inspect the parameters then, but a crash is not very helpful either.

[An_N_1]

I mean , setting 'Information for PARAMETER Constants' to none, doesn't help in this case.

It will still crash. 

[Arjen_Markus]

Then, I am afraid, I have no idea what is wrong.

[IanH · Accepted solution]

A local variable that is an array that has a size that depends on a dummy argument (which is a form of automatic variable in Fortran terminology) is often stored on the stack - as its size may vary each time the procedure is called.

By default, the stack on Windows is only about one megabyte.  Your array requires about four megabytes.  Four megabytes does not fit in one megabyte.

You either need to:

- increase the stack size (in the Visual Studio properties for the executable, this is under Linker > System > Stack Reserve Size)

- tell the compiler that temporary arrays should be stored on the heap (in Visual Studio this is under Fortran > Optimization > Heap Arrays, set it to zero).

When you make the array size a constant, the compiler can set aside "static" storage for the array (i.e. not on the stack), as the storage required for the array is known at compile time.

[andrew_4619]

The error is because you overflowed the stack. If you take a zero off the N value there is no overflow. That said is seems wrong to me to be using an arg to dimension a local  array that is not an arg. It would make more sense to allocate that local using the passed arg and you would have it on the heap rather than the stack.

[An_N_1]

Thanks IanH!

Both suggestions are helpful!

I have modified  Stack Commit Size, it doesn't work. So I didn't change reserve size option, and posted the question here.

BTW, in older version of ivf, such as 2015/2012 i used before, setting stack commit size will aviod the stack overflow of the same code.

I don't know why?

[An_N_1]

I am sorry, the question posted here is invalid.

Increasing stack reseve size is OK. And increasing commit size is always useless in each version.

[John_Campbell]

Rather than using the stack for the "Automatic" array, you can use an ALLOCATE array, which will go on the heap, then not need selection of any special compile options. This would be a more robust approach, eg:

program Console2

    call foo(1000000)

end program Console2

subroutine foo(N)

  implicit none
  integer :: N

  integer, ALLOCATABLE :: a(:)

!  executable statements
  ALLOCATE ( A(N) )
 

end subroutine

Note that ALLOCATE is an executable statement, not a declaration.
N can be much larger, say 100 million, or 1 billion in 64-bit environment.
You should review the documentation of ALLOCATE arrays, as they offer a number of advantages, but you need to consider the scope of the array.