Stack overflow on subroutine call only when compiling using Intel Visual Fortran and excellent when compiling Compaq Visual Fortran

Question

Using identical source files for a Fortran.dll file I can compile them using Compaq Visual Fortran 6.6C or Intel Visual Fortran 12.1.3.300 (IA-32). The problem is that execution is not performed in the Intel binary, but works well with Compaq. I am building a 32-bit version on a 64-bit Windows 7 system. The .dll call driver is written in C# .

The error message comes from the dangerous call to _chkstk() when the internal routine is called (called from the .dll input procedure). (SO answer to chkstk() )

The procedure in question is declared as (pardon format format format)

  SUBROUTINE SRF(den, crpm, icrpm, inose, qeff, rev, & qqmax, lvtyp1, lvtyp2, avespd, fridry, luin, & luout, lurtpo, ludiag, ndiag, n, nzdepth, & unit, unito, ier) INTEGER*4 lvtyp1, lvtyp2, luin, luout, lurtpo, ludiag, ndiag, n, & ncp, inose, icrpm, ier, nzdepth REAL*8 den, crpm, qeff, rev, qqmax, avespd, fridry CHARACTER*2 unit, unito 

and is called like this:

  CALL SRF(den, crpm(i), i, inose, qeff(i), rev(i), & qqmax(i), lvtyp1, lvtyp2, avespd, fridry, & luin, luout, lurtpo, ludiag, ndiag, n, nzdepth, & unit, unito, ier) 

with similar variable specifications except crpm , qeff , rev and qqmax are arrays for which only i-th used for each call to SRF() .

I understand the possible stack problems if the arguments are larger than 8kb in size, but in this case we have 7 x real(64) + 11 x int(32) + 2 x 2 x char(8) = 832 bits only in the arguments passed .

It was very difficult for me to move the arguments (especially arrays) to the module, but I still get the same error

.

Unpacking with Intel .dll

Unpacking with Compaq .dll

Can anyone suggest any suggestions on what causes SO, or how to debug it?

PS. I have increased the reserved stack space to hundreds of Mb and the problem persists. I tried to skip the chkstk() call in dissasembler, but in case of program crashes. The stack check starts at address 0x354000 and 0x354000 through to 0x2D2000 when it crashes on the protection page. The bottom address of the stack is 0x282000 .

Answer 1

You shoot the messenger. The generated Compaq code also calls _chkstk (), the difference is that it entered it. General optimization. The key difference between the two fragments:

  mov eax, 0D3668h 

against

  sub esp, 233E4h 

The values ​​you see here are the amount of stack space required by the function. Intel code requires 0xd3668 bytes = 865869 bytes. Compaq code requires 0x233e4 = 144356. A big difference. In both cases, when most, but Intel, becomes critical, the program usually has one megabyte stack. Compressing to 0.86 megabytes from it very much brings it closer, embeds several function calls, and you look at this site name.

What you need to find out, I can not help, because it is not in your fragment, so the function generated by Intel requires so much space for local variables. Workarounds - Use a free store to find space for large arrays. Or use the / STACK linker option to request more stack space (guess the option name).