Peter Shenkin wrote:
>Suppose I have a program that looks like this:
>
>PROGRAM testfoo
>  CALL foo( 1000000 )
>END 
>SUBROUTINE foo( n )
>  INTEGER :: n
>  DOUBLE :: x( n, n, n, n )
   ^^^^^^

Too much programming in C...

>  x = 1
>END
>
>Most UNIXes will give you a SEGV when you start to execute foo.

On 32-bit systems this has little to do with automatic allocation and a lot to
do with integer overflow.  (Hint: in 32-bit arithmetic, n*n*n*n*8==134217728
which is rather too small - the request will succeed (in allocating the wrong
amount) and so "x=1" tries to write to unallocated memory, thus SEGV).

Production of a "SEGV" is IMO a Quality-of-Implementation issue; we (NAG) have
always produced informative messages on automatic array allocation failure.

OTOH, the usual reason for automatic array allocation failure seems to be
running out of "stack space" rather than memory - again, we allocate big
arrays on the heap so we don't usually suffer from this problem.

(Unfortunately we don't yet catch the integer overflow in memory allocation
request size calculations; that is on the list of things to beef up for the
next release.)

>Now compare this with the situation where foo instead looks like
>this:
>
>SUBROUTINE foo( n )
>  INTEGER :: n
>  INTEGER :: status
>  DOUBLE,ALLOCATABLE :: x( :, :, :, : )
>  ALLOCATE( X(n,n,n,n), STAT=status ) 
>  IF( status .NE. 0 ) STOP 'foo: could not allocate x'
>  x = 1
>END

And in this case the exact same thing occurs for 32-bit systems/compilers
(I tried several) though a 64-bit compiler does produce your desired result.
However, if you replace your "100000" with "2**20", the 64-bit system gets
an integer overflow as well (X takes up (2**20)**4*8 = 2**83, which mod
2**64 == 512k) and the allocation request succeeds in allocating the wrong
amount of memory and you get a SEGV.

Perhaps you should insert
  IF (N>(HUGE(0)**0.25)/8) STOP 'Ridiculous amount of memory requested'
before the ALLOCATE statement?

(Or if you're confident of running on a 64-bit compiler, do the fourth root
yourself, viz "N>(2**16)/8").

I'm not entirely joking - very few systems detect integer overflow in
size calculations (or anywhere else for that matter).

>> This is especially important because a lot of dynamic
>> allocation might take place in a loop like
[code snipped]
>I'm obviously missing something here.  I don't see any allocation 
>(static or dynamic) at all in that example; I don't see any declarations 
>of automatic arrays or ALLOCATE calls.

Probably a compiler-generated array temp.  These things do happen you know...

...and one would hope that a good QoI would mean that an informative error
message is produced when running out of memory here rather than an
uninformative SEGV.

Cheers,
-- 
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
                           ([log in to unmask])


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%