dynamic array pointer assignment gives segmentation error

[windmaomao1]

ok, here is the problem, if i do the following, it gives me segmentation error if i do ifort without any flag. and if i change the -1:30 (third index) to -1:20, it works.

and if i change this pointer type to Allocatable, it works without problem. so how do I do the assignment properly.

ifort version is 10.1.008 and 10.1.006, both have the same problem, the machine is linux fedora.

can anybody help ? thanks.

PROGRAM test
IMPLICIT NONE

REAL, DIMENSION(:,:,:,:), POINTER :: a,b
INTEGER :: ierror

ALLOCATE (&
a(-1:130,-1:130,-1:30,1:6), &
b(-1:130,-1:130,-1:30,1:6), &
STAT=ierror)

a=b
print *,ierror

DEALLOCATE(a,b)

END PROGRAM test

[Xiaoping_D_Intel]

Looks like a lack of user stack size problem. Would you please check its sizeby "ulimit -s" and set it to a larger size?

[jimdempseyatthecove]

What happens if you replace "a=b" with a 4-level do loop?

(I know you want the "a=b")

If the problem goes away then this indicates the compiler is generating

! a=b
= b
a =

And this definitely is not the code you intend to be generated. Unnecessary stack temporary creation is a compiler error (IMHO) and should be corrected.

If this is the problem then if newer version of compiler available try that first. Else insert preprocessor directives to perform the copy

! BugFix.inc
#define BUG_ArrayCopy
#ifdef BUG_ArrayCopy
#define call fppCOPY(Aout, Ain, size(Aout),size(Ain))
#else
Aout = Ain
#endif
...
! fppCOPY.F90
subroutine fppCOPY(Aout, Ain, Nout, Nin)
integer :: Nout, Nin
real :: Aout(Nout), Ain(Nin)
integer :: N
N=min(Nout,Nin)
Aout(1:N) = Ain(1:N)
if(Nout .gt. N) Aout(N+1:Nout) = 0.0
end subroutine fppCOPY
...
! YourSubroutine
#include "BugFix.inc"
...
fppCopy(a,b)
...

Yes it is a hack but at least it will get you going without a performance penalty. And you can create a small test suit to verify if the problem is corrected on later releases of the compiler. You might want to insert diagnostic code

if (Nout .ne. Nin) call YourBugCheck()

Jim Dempsey

[TimP]

The compile option -check arg_temp_created should tell whether you are affected by the pitfall which Jim mentioned, as would a look at the generated asm code. Newest Intel compilers should recognize a whole array copy as one which can be performed by a library function, and make the substitution automatically.

[Steven_L_Intel1]

I don't think the stack limit is involved, nor will the arg_temp_created diagnostic help here as there is no argument. My guess is that the allocate of B is failing, though the total size seems rather small to me. Print ierror BEFORE the assignment and see, or take off the stat= option.

[jimdempseyatthecove]

Tim,

I find -check:arg_temp_created useless (for the most part) since this is a run time check as opposed to a compile time information message. There should be a -warn:arg_temp_created IMHO.

Jim Dempsey

[Steven_L_Intel1]

It can't do it at compile-time because there is a run-time check for contiguity. If the argument is contiguous, no temp is created.

[TimP]

I haven't seen the case where a decision is made at run time whether to create a temporary, although it may be the case in the situation under discussion here. I generally find the undesirable temporaries by compiling with -S and looking for the dynamic allocation of the temporary, or the code which copies from the temporary to the final location. In ifort 9.x and 10.x, it was fairly common to create a temporary and store to it, even when the compiler recognized that the temporary was not needed, and stored both to the temporary and the destination in the same loop.
The beta compiler has eliminated the case where data are stored to an unused temporary. It uses an _intel_fast_memcpy() to move data from a temporary, sometimes avoiding a loss of performance, but not avoiding the consumption of additional memory.
OP has not divulged which compiler version is under discussion, unless I missed it.

[Steven_L_Intel1]

The OP did give the version, and there are no routine calls in the OP's code so there's no arguments to generate temps for. I'm sure that the issue is one or both of the ALLOCATEs failed.