Re: g77 large array

Re: g77 large array

[Robert Dewar]

> In this case, two arrays do not need memory at the same time.
> Cannot SUBROUTINE B use the same memory area as A in Fortran compiler,
> even if I do not declare explicitly COMMON I?
> I should write about the machine.

Usually convention in Fortran is to allocate all storage statically. So indeed
one would not expect these two arrays to overlap. I am not sure about the current
Fortran standard, but earlier Fortran standards certainly *allowed* stack allocation
of such arrays, but in practice, static allocation (also certainly allowed) was
so standard, that all compilers do static allocation.

So what you are seeing makes perfect sense

Re: g77 large array

[Dale Johannesen]

On Tuesday, October 14, 2003, at 08:00  PM, Robert Dewar wrote:

>> In this case, two arrays do not need memory at the same time.
>> Cannot SUBROUTINE B use the same memory area as A in Fortran compiler,
>> even if I do not declare explicitly COMMON I?
>
> Usually convention in Fortran is to allocate all storage statically. 
> So indeed
> one would not expect these two arrays to overlap. I am not sure about 
> the current
> Fortran standard, but earlier Fortran standards certainly *allowed* 
> stack allocation
> of such arrays, but in practice, static allocation (also certainly 
> allowed) was
> so standard, that all compilers do static allocation.

Actually, most modern Fortran compilers have a switch to control this.  
g77 documents
-fautomatic to do what you want.   I haven't tried it; the doc also 
claims it is the default, so
it may not be working right in your environment, or it may have some 
limit on how much
stack space it will allocate.

Re: g77 large array

[Toon Moene]

Dale Johannesen wrote:

> On Tuesday, October 14, 2003, at 08:00  PM, Robert Dewar wrote:
> 
>>> In this case, two arrays do not need memory at the same time.
>>> Cannot SUBROUTINE B use the same memory area as A in Fortran compiler,
>>> even if I do not declare explicitly COMMON I?

> Actually, most modern Fortran compilers have a switch to control this.  
> g77 documents
> -fautomatic to do what you want.   I haven't tried it; the doc also 
> claims it is the default, so
> it may not be working right in your environment, or it may have some 
> limit on how much
> stack space it will allocate.

Well, the reason to have a maximum-size-to-put-on-the-stack for arrays 
when the first release of g77 was made (early '95) was that a lot of the 
target systems had small stack sizes (by default and as a system wide 
maximum).  If the compiler just allocated arbitrarily sized arrays on 
the stack, much more people would have run into segmentation faults than 
are now.

However, g77 (like all of GCC) is free software.  You can up the limit 
yourself (and rebuild the compiler).  The limit is in the file 
gcc/f/com.c, constant FFECOM_sizeMAXSTACKITEM.

Hope this helps,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Re: g77 large array

[Dale Johannesen]

On Wednesday, October 15, 2003, at 11:31  AM, Toon Moene wrote:
> Dale Johannesen wrote:
>> On Tuesday, October 14, 2003, at 08:00  PM, Robert Dewar wrote:
>>>> In this case, two arrays do not need memory at the same time.
>>>> Cannot SUBROUTINE B use the same memory area as A in Fortran 
>>>> compiler,
>>>> even if I do not declare explicitly COMMON I?
>
>> Actually, most modern Fortran compilers have a switch to control 
>> this.  g77 documents
>> -fautomatic to do what you want.   I haven't tried it; the doc also 
>> claims it is the default, so
>> it may not be working right in your environment, or it may have some 
>> limit on how much
>> stack space it will allocate.
>
> Well, the reason to have a maximum-size-to-put-on-the-stack for arrays 
> when the first release of g77 was made (early '95) was that a lot of 
> the target systems had small stack sizes (by default and as a system 
> wide maximum).  If the compiler just allocated arbitrarily sized 
> arrays on the stack, much more people would have run into segmentation 
> faults than are now.

Sounds like a good place for a compile-time default and command-line 
switch to override.

> However, g77 (like all of GCC) is free software.  You can up the limit 
> yourself (and rebuild the compiler).  The limit is in the file 
> gcc/f/com.c, constant FFECOM_sizeMAXSTACKITEM.
>
> Hope this helps,

Not me; just delurked for a moment to help susukita...let us know what 
you come up with....

Re: g77 large array

[Susukita Ryutaro]

> > However, g77 (like all of GCC) is free software.  You can up the limit 
> > yourself (and rebuild the compiler).  The limit is in the file 
> > gcc/f/com.c, constant FFECOM_sizeMAXSTACKITEM.
> >
> > Hope this helps,
> 
> Not me; just delurked for a moment to help susukita...let us know what 
> you come up with....

Thank you for useful information on large arrays in Fortran compilers.
If I change FFECOM_sizeMAXSTACKITEM to solve the problem, I must
request other users to change FFECOM_sizeMAXSTACKITEM and rebuild g77
when I distribute the program as a source. It is usually difficult.
But changing FFECOM_sizeMAXSTACKITEM is a solution when I use the
program only on my environment.

SUSUKITA, Ryutaro
The Institute of Physical and Chemical Research (RIKEN)
Computational Astrophysics Laboratory

Re: g77 large array

[Susukita Ryutaro]

> >       CALL A
> >       CALL B
> >       END
> > 
> >       SUBROUTINE A
> >       INTEGER I(33554432)
> >       I(33554432) = 0
> >       END
> > 
> >       SUBROUTINE B
> >       INTEGER I(8388608)
> >       END
> 
> Note that this program needs ~ 4 * (33.5 + 8.4) = 4 * 42 = 168 Mbyte of 
> RAM+SWAP.  What's the size of your machines' RAM + SWAP ?

In this case, two arrays do not need memory at the same time.
Cannot SUBROUTINE B use the same memory area as A in Fortran compiler,
even if I do not declare explicitly COMMON I?
I should write about the machine. The machine's RAM + SWAP = 48 M +
128 M = 176 M, so if two arrays need different memory areas, the
program will fail.

SUSUKITA, Ryutaro
The Institute of Physical and Chemical Research (RIKEN)
Computational Astrophysics Laboratory

Re: g77 large array

[Toon Moene]

Susukita Ryutaro wrote:

> This may not be a bug, but I hope it will be fixed.

[ ... Segmentation fault .... ]

>       CALL A
>       CALL B
>       END
> 
>       SUBROUTINE A
>       INTEGER I(33554432)
>       I(33554432) = 0
>       END
> 
>       SUBROUTINE B
>       INTEGER I(8388608)
>       END

Note that this program needs ~ 4 * (33.5 + 8.4) = 4 * 42 = 168 Mbyte of 
RAM+SWAP.  What's the size of your machines' RAM + SWAP ?

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

g77 large array

[Susukita Ryutaro]

This may not be a bug, but I hope it will be fixed.

      CALL A
      END

      SUBROUTINE A
      INTEGER I(33554432)
      I(33554432) = 0
      END

I can compile and execute the program successfully like:

> g77 test.f
> ./a.out

But if I add SUBROUTINE B, it fails with 'Segmentation fault'. 

      CALL A
      CALL B
      END

      SUBROUTINE A
      INTEGER I(33554432)
      I(33554432) = 0
      END

      SUBROUTINE B
      INTEGER I(8388608)
      END

Even if I do not call B, it fails with 'Segmentation fault'. 

      CALL A
      END

      SUBROUTINE A
      INTEGER I(33554432)
      I(33554432) = 0
      END

      SUBROUTINE B
      INTEGER I(8388608)
      END

My environment is

> g77 -v
Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.3.1/specs
Configured with: ./configure --enable-languages=f77
Thread model: posix
gcc version 3.3.1

SUSUKITA, Ryutaro
The Institute of Physical and Chemical Research (RIKEN)
Computational Astrophysics Laboratory