run time errors, stack size

[hermannl]

Does anyone know, whether the treatment of allocatable arrays and pointers has changed from ifort 9.1.040 to 9.1.041?

Dealing with large (allocatable) arrays, I observe segfaults in 9.1.041 where 9.1.040 ran without any problems. The segfault appears under the following circumstances:

i) a large arrayhas beensucessfully allocated an filled with data

ii) a copy of the array is to be stored by means of an allocatable array as follows:
first, the new array is allocated andallocation runs without problems
next, the array is to be copied (just as new_array = original_array)

in the second setp in ii) the segfault happens in 9.1.041, but not in 9.1.040!

It turned out that the segfault can be circumvented by do loops (do i=1,SIZE(original_array).....), increasing the stack size, or using the compiler option -heap-arrays. This optionI found mentioned by Steve in a reply to another post but have not been able to look-up in the compiler documentation. Any hint where to find it?

Hermann

[Steven_L_Intel1]

Not that I am aware of. 9.1.041 has improvements in the elmination of unnecessary stack temps, however. The switch you are looking for is -heap-arrays and is described in the release notes.

I would ask that you submit a test case to Intel Premier Support, as a program which worked in 9.1.040 and doesn't in 041 could mean a compiler bug.

[hermannl]

Dear Steve,

thanks for mentioning the release notes - I missed that!

Regarding the test case - I will do my very best. I already tried to reduce the problem, however, up to now I did not succeed: the problem only shows up in the complete program (some 100.000 lines of code), reduction to a few lines is still missing.

Hermann

[Steven_L_Intel1]

We'll take the whole program if you find reducing it difficult.

[hermannl]

Hi Steve,

I could reduce the problem to a few lines and reported that to premier support as you suggested. As it turned out, the problem stemmed actually from a bug fix in9.1.041. Therefore, the segfault did not occurin 9.1.040.

At the moment, the best solution for meseems to be the use of the heap-arrays flag,which works under Linux and Windows as well.

Best, Hermann

[Steven_L_Intel1]

Right - the developer came over and told me what was happening. In previous versions, the compiler was skipping the check for potential overlap in an assigmnent such as:

a%b = c

where either b or c was a POINTER. This could result in incorrect behavior if the pointers overlapped. Now it realizes that it can't tell if there is an overlap and creates a temp. You can avoid the problem by using ALLOCATABLE instead of POINTER because the semantics of the language do not allow for different ALLOCATABLEs to overlap.

[hermannl]

Hi Steve,

the "problem" with allocatable arrays, in the specific case here, is that the arrays are components of a user defined (matrix) type. As far as I know, the use of allocatable arrays in this context conflicted with the FORTRAN 90 and 95 standards (and, as far as I remember, caused compilation failure of the corresponding program unit with former Intel Fortran compilers). I just checked the Fortran 2003 standard, and things seems to have changed. Also Icompiled a simple test example (only specification of the matrix type) using allocatable arrays as type components and it seems to work. SoI guessthatIntel Fortran 9.1.xxx does support this Fortran 2003 feature- which is good news for me.

Best,

Hermann

[Steven_L_Intel1]

Yes, allocatable components of a derived type is a F2003 feature but is one that has been supported in Intel Fortran since version 8.0 and is also supported by most other F95 compilers on the market.