Apparent increase in stack memory usage following upgrade to ifort 2017u6

[Craig_T_]

My organization has recently upgraded the Intel compiler we use for our software from Intel Fortran 2013 SP1 update 3 to Intel Fortran 2017 update 6.

However, we have observed that our software now encounters from stack overflows for both non-optimized debug and optimized release runs of the ifort2017u6 build, whereas corresponding ifort2013u3 builds both run without any stack overflow encountered. These builds are using the same source code and compiler settings were set to be effectively similar.

This is concerning to us, since we do have a deliberately capped /STACK reserve size for our software and we don't want to be unable to run any simulations that previously ran.

I was also able to corroborate an increase in stack memory usage using the new compiler by comparing the loc() address of an integer at the top of the call stack with a loc() of a local further down. If I compare the stack memory address for the routine that encounters the overflow, I see it corresponds to about 15% more stack memory usage.

I'm seeking to learn about any programming styles that may cause the new compiler's stack memory usage to swell compared to the older 2013 SP1 update 3 compiler, and/or if there are any Intel tools that may help troubleshoot this change in stack memory usage problem.

[Steve_Lionel]

/noheap-arrays has always existed and still works. Hundreds of customers have complained over the years of the use of the stack for temporaries and automatic arrays, and most competing compilers already do something similar. I will note that in the majority of cases, there is no test - the space is just allocated on the heap. As Lorri says, the value you can specify on the option is tested at compile-time, so it has no effect on performance. (It is also a rather useless option since the cases where the compiler even looks at this are unusual.)

[Craig_T_]

Thanks for the clarification Steve. I indeed had missed Lorri's (in hindsight well-stated) original point about /heap-arrays:n being prone to just placing on heap without any size test.

This suggests then that the significant 14-27% slower performance is a result of heap instead of stack usage itself (and not testing). So a finer point is made there, albeit this ultimately does not change the problem faced by ifort version upgraders.

Given the apparent sensitivity of performance and stack overflow potential to this temporary array stack/heap maneuvering, I'm disappointed and surprised that Intel would choose not to tread lightly and maintain a flag to disable new more stack-aggressive compiler developments. Now that it's hard-coded, it disincentivizes Intel compiler upgrades.

[Steve_Lionel]

There IS a flag - we've been trying to tell you that. 

However, as far as I can tell the default has not changed - it is still to put temporaries on the stack. At least that's what the 18.0 documentation says.

At this point, rather than guessing, you should run your program under a profiler such as Intel VTune Amplifier XE, and see where it is really spending its time.

[jimdempseyatthecove]

>>This is concerning to us, since we do have a deliberately capped /STACK reserve size for our software and we don't want to be unable to run any simulations that previously ran.

I would venture to guess that at some point in the past someone ran a test to find the minimum stack reserve size is for a specific application .AND. test data. It appears that it is time for someone to re-do this test.... and provide a reasonable amount of slack space.

Jim Dempsey