This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: automatic arrays in g77
- To: N8TM at aol dot com
- Subject: Re: automatic arrays in g77
- From: Martin Kahlert <martin dot kahlert at mchp dot siemens dot de>
- Date: Wed, 9 Feb 2000 07:39:31 +0100
- Cc: gcc at gcc dot gnu dot org
- References: <78.1268073.25d198d6@aol.com>
- Reply-To: martin dot kahlert at mchp dot siemens dot de
Quoting N8TM@aol.com (N8TM@aol.com):
> >how can i tell g77, that a big array (double precision >with >= 4097 elements
> > in my particular case) should be put on the stack >instead of static storage?
> > 4096 seems to be the limit for g77.
>
> g77 does support automatic arrays, which are allocated at the time of entry to a subroutine,
> and released automatically at return. They are intended to operate in accordance with f90/f95.
> I suspect this feature needs some of the stress testing you are likely to give it.
> Allocation on stack vs heap is not under control of g77 but depends presumably
> on the implementation of underlying libc calls. Of course, local arrays of fixed
> dimension not SAVEd also are expected to be allocated at time of subroutine entry,
> but are not called automatic in Fortran terminology.
That's not true, and that's exactly my problem.
Try:
SUBROUTINE F(V,N)
INTEGER*4 SIZE
PARAMETER(SIZE=4097)
REAL*8 V,X(SIZE)
INTEGER*4 I,N
IF (N .GT. 0) THEN
DO I=1, SIZE
IF(X(I) .EQ. 18D0) WRITE(*,*) i
ENDDO
ELSE
DO I=1, SIZE
X(I) = V
ENDDO
CALL G
ENDIF
RETURN
END
SUBROUTINE G
CALL F(1D0, 1)
RETURN
END
CALL F(18D0, 0)
END
(I know, it's illegal FORTRAN because it uses a recursive call)
Please compare its output with the one you obtain when you change SIZE to 4096!
Small local arrays with fixed size are allocated on the stack, big ones are not.
> If you are seeing a limitation of BIGARRAY(4096,4096), this may not be affected
> by the use of automatic vs static allocation; it is probably a limit of the gnu back end,
> discussed here recently, where arrays are limited to the number of bits described by a default INTEGER.
No, that's another problem.
Thanks for your reply,
Martin.
--
The early bird gets the worm. If you want something else for
breakfast, get up later.