TRANSFER and HEAP prpoblem

[nvaneck]

I have a module with the following definitions in it: REAL(8) X_D(MAXB/8) CHARACTER(MAXB) X_C where MAXB is 80000 When HEAP is not specified, all works fine. If I specify HEAP with any value, I get an access violation with the statement X_D=TRANSFER(X_C,0D0,NV) where NV is 1 (or anything, I presume). In debug I can see X_D and X_C. What can cause this? I've tried HEAP 0, 10, 80, 100, 200 all with same results. Why does it affect data defined in a module? Using Intel(R) Visual Fortran Composer XE 2011 Update 7

[Steven_L_Intel1]

Are you referring to /heap-arrays? The value you specify, other than 0 (when in Visual Studio), isn't meaningful.

I would not expect the behavior you describe. Please provide a small but complete test case we can look at.

[nvaneck]

I'm Working on a smaller test. It does look like the transfer works, but then crashes when it comes back from it. I'm just using heap_arrays 0 to test, but I noticed that if I specify a non-zero value, it does show up in the command line....in VS2010.

[nvaneck]

Small program exhibiting problem when HEAP_ARRAYS 0 MODULE SPACE IMPLICIT NONE SAVE INTEGER(4),PARAMETER ::MAXB=80000 REAL(8) X_D(MAXB/8) CHARACTER(MAXB) X_C END MODULE SPACE PROGRAM MicrOsiris USE SPACE IMPLICIT NONE INTEGER(4) NP SAVE 50 NP=2 X_C=' ' X_D=0D0 X_D=TRANSFER(X_C,0D0,np) !crashes here END

[Steven_L_Intel1]

Thanks - I can reproduce this and will send it on to the developers.

[Steven_L_Intel1]

Issue ID is DPD200255980.

[Steven_L_Intel1]

Sorry to have taken so long on this, but it turns out that this is a programming error. The TRANSFER in effect is:

X_D=TRANSFER(X_C,0D0,2)

where X_D is a 10000 element array of REAL(8).

The "2" in the TRANSFER is the SIZE argument, which specifies the number of elements in the "physical result" of the TRANSFER. So the TRANSFER result is a 2-element array of type REAL(8) and assigning a 2-element array to a 10000 element array is a shape mismatch. Unfortunately, we don't have shape checking implemented so we didn't give a more reasonable error for this.

The use of heap_arrays was a bit of a red herring - what happens in this case is that the compiler picks one side or the other for determining the amount of data to move, and with heap arrays, this ran off the end of allocated address space.