[patch, fortran] PR32124 - Don't give a run-time error if stat= has been specified for ALLOCATE

[Brooks Moses]

At 12:28 PM 5/29/2007, Tobias Burnus wrote:
>Brooks Moses wrote:
> > This test is failing on powerpc-apple-darwin8.9.0; both of the status
> > variables are 0.
>I assume the following happens: The variable overflows such that it is a
>relatively small number. malloc sees this number, allocate some memory
>and returns.
[...]
>Have a look in the dump at the size variable, passed to _gfortran_allocate*.

   a.dtype = 540;
   a.dim[0].lbound = 1;
   a.dim[0].ubound = 2147483647;
   a.dim[0].stride = 1;
   a.dim[1].lbound = 1;
   a.dim[1].ubound = 2147483647;
   a.dim[1].stride = 2147483647;
   a.dim[2].lbound = 1;
   a.dim[2].ubound = 2147483647;
   a.dim[2].stride = 1;
   a.dim[3].lbound = 1;
   a.dim[3].ubound = 2147483647;
   a.dim[3].stride = 2147483647;
   a.data = _gfortran_allocate_array (a.data, 8, &stat.0);

That doesn't look like it's allocating an especially big array, no -- it's 
only one element long!  The stride values are also broken in interesting ways.

>My problem is: How to get a negative number on both 32bit and 64bit
>system. For 32bit the following is negative:
>
>real(8), allocatable :: A(:)
>allocate(A(huge(0_4)/7))
>end
>
>But on 64bit systems it is not and the system migher actually attempt to
>allocate that much memory. Using 0_8 gives an overflow on 32bit systems
>and gfortran might not compile the program.
>
>Any ideas? (I knew why I did not want to have a test case when I
>originally submitted the patch.)

It would be nice if the runtime library could error out on when the size 
overflows, without needing to rely on the result ending up negative.

- Brooks