G77 problem and help needed

G77 problem and help needed

[Martin Gruenewald]

Dear experts on G77;

I have three FORTRAN77 routines which do not compile with G77 version
2.91.66 - they also do not compile with a January-snapshot of GCC3:

The error messages are always the same for the three cases:



g77  -O -fno-automatic -fdollar-ok -fno-backslash             -finit-local-zero -fno-second-underscore -fugly-logint             -ftypeless-boz -fno-f90 -fugly-complex -c xsectfit.f
xsectfit.f: In block-data `xsect_fit':
xsectfit.f:8: warning:
         DATA XSECTFIT_LN(1) /"Begin:data_xsect.fit"/
                              ^
Initialization of large (4592500-unit) aggregate area `xsectfit_ln' at (^) currently very slow and takes lots of memory during g77 compile -- to be improved in 0.6
xsectfit.f:7: warning:
         COMMON /XSECTFIT / XSECTFIT_LN
                 ^
Initialization of large (4592500-unit) aggregate area `xsectfit' at (^) currently very slow and takes lots of memory during g77 compile -- to be improved in 0.6
xsectfit.f:5566: virtual memory exhausted



g77  -O -fno-automatic -fdollar-ok -fno-backslash             -finit-local-zero -fno-second-underscore -fugly-logint             -ftypeless-boz -fno-f90 -fugly-complex -c wtmxsmp1.f
wtmxsmp1.f: In block-data `wtmx_smp1':
wtmxsmp1.f:8: warning:
         DATA WTMXSMP1_LN(1) /"Begin:data_wtmax.fit.smp1"/
                              ^
Initialization of large (4093606-unit) aggregate area `wtmxsmp1_ln' at (^) currently very slow and takes lots of memory during g77 compile -- to be improved in 0.6
wtmxsmp1.f:7: warning:
         COMMON /WTMXSMP1 / WTMXSMP1_LN
                 ^
Initialization of large (4093606-unit) aggregate area `wtmxsmp1' at (^) currently very slow and takes lots of memory during g77 compile -- to be improved in 0.6
wtmxsmp1.f:5140: virtual memory exhausted




g77  -O -fno-automatic -fdollar-ok -fno-backslash             -finit-local-zero -fno-second-underscore -fugly-logint             -ftypeless-boz -fno-f90 -fugly-complex -c wtmxsmp2.f
wtmxsmp2.f: In block-data `wtmx_smp2':
wtmxsmp2.f:8: warning:
         DATA WTMXSMP2_LN(1) /"Begin:data_wtmax.fit.smp2"/
                              ^
Initialization of large (4079764-unit) aggregate area `wtmxsmp2_ln' at (^) currently very slow and takes lots of memory during g77 compile -- to be improved in 0.6
wtmxsmp2.f:7: warning:
         COMMON /WTMXSMP2 / WTMXSMP2_LN
                 ^
Initialization of large (4079764-unit) aggregate area `wtmxsmp2' at (^) currently very slow and takes lots of memory during g77 compile -- to be improved in 0.6
wtmxsmp2.f:5139: virtual memory exhausted



All three routines are rather long BLOCKDATA routines. While the
compiler warns about large aggregate areas, it should still at least
compile them, rather than abort.  After all, not much complicated code
is needed to stuff some data somewhere, I would think.

Anyway, I would appreciate a set of G77 options with which I could
compile these routines (as I can do with the native f77 compilers
under HP-UX and SGI/IRIX). It seems to be "legal" FORTRAN, so G77
should compile it!


You can pick up the offending code at:

http://l3www.cern.ch/homepages/gruenew/wtmxsmp1.f
http://l3www.cern.ch/homepages/gruenew/wtmxsmp2.f 
http://l3www.cern.ch/homepages/gruenew/xsectfit.f


Thanks and best regards

Martin


--

Martin W. Gruenewald                   Humboldt University Berlin (HUB)
http://l3www.cern.ch/homepages/gruenew/welcome.html

CERN EP/L3 32-2C07                     e-mail: Martin.Grunewald@cern.ch
CH-1211 Geneva 23                      Phone:  ++41-22-76 79927, 79875, 74477
Switzerland                            Fax:    ++41-22-78 28923

Re: G77 problem and help needed

[Alexandre Oliva]

On Feb 24, 2001, Martin Gruenewald <Martin.Grunewald@cern.ch> wrote:

> All three routines are rather long BLOCKDATA routines. While the
> compiler warns about large aggregate areas, it should still at least
> compile them, rather than abort.

It only aborts because it runs out of virtual memory.  Give it enough
time and virtual memory and it will eventually complete.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: G77 problem and help needed

[Martin Gruenewald]

Hello;;

On 24 Feb 2001, Alexandre Oliva wrote:

> On Feb 24, 2001, Martin Gruenewald <Martin.Grunewald@cern.ch> wrote:
> 
> > All three routines are rather long BLOCKDATA routines. While the
> > compiler warns about large aggregate areas, it should still at least
> > compile them, rather than abort.
> 
> It only aborts because it runs out of virtual memory.  Give it enough
> time and virtual memory and it will eventually complete.
> 
> -- 

Well, no: seeing the error message I tried it on a 256MB RAM and 512MB
swap system (Linux 2.2), and it still does not compile. In fact, I
have not found any system on which it compiles, which tells me that
G77 just uses too much resources for a task which, when done
sequential when reading the file, should be doable with tiny memory
requirements.

Do you have other ideas? A hidden flag to tell G77 not to do anything
fancy? I tried various combinations of options but without success.

Thanks and best regards

Martin

--

Martin W. Gruenewald                   Humboldt University Berlin (HUB)
http://l3www.cern.ch/homepages/gruenew/welcome.html

CERN EP/L3 32-2C07                     e-mail: Martin.Grunewald@cern.ch
CH-1211 Geneva 23                      Phone:  ++41-22-76 79927, 79875, 74477
Switzerland                            Fax:    ++41-22-78 28923

Re: G77 problem and help needed

[Alexandre Oliva]

On Feb 24, 2001, Martin Gruenewald <Martin.Grunewald@cern.ch> wrote:

> Well, no: seeing the error message I tried it on a 256MB RAM and 512MB
> swap system (Linux 2.2), and it still does not compile.

Well, in all cases, it ran out of virtual memory.  And it warned it
needed a lot of memory for those constructs in advance, and that a fix
is planned.  It just hasn't been implemented (or so you said).  Maybe
you're willing to contribute a fix?  If you feel you don't have the
expertise, you may still help by donating resources to someone who
does.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: G77 problem and help needed

[Martin Gruenewald]

Hi;

On 24 Feb 2001, Alexandre Oliva wrote:

> On Feb 24, 2001, Martin Gruenewald <Martin.Grunewald@cern.ch> wrote:
> 
> > Well, no: seeing the error message I tried it on a 256MB RAM and 512MB
> > swap system (Linux 2.2), and it still does not compile.
> 
> Well, in all cases, it ran out of virtual memory.  And it warned it
> needed a lot of memory for those constructs in advance, and that a fix
> is planned.

Seems since a long time  ..............................

> It just hasn't been implemented (or so you said). 

.... said by the compiler....

> Maybe you're willing to contribute a fix? 

Yes, but: 

> If you feel you don't have the
> expertise, 

Indeed, as I do not know any G77 internals! Would it be easy to learn?
Do you have some pointers to start looking?

> you may still help by donating resources to someone who does.

To whom, what and how?

Let me know.

Best regards

Martin

--

Martin W. Gruenewald                   Humboldt University Berlin (HUB)
http://l3www.cern.ch/homepages/gruenew/welcome.html

CERN EP/L3 32-2C07                     e-mail: Martin.Grunewald@cern.ch
CH-1211 Geneva 23                      Phone:  ++41-22-76 79927, 79875, 74477
Switzerland                            Fax:    ++41-22-78 28923

Re: G77 problem and help needed

[Alexandre Oliva]

On Feb 24, 2001, Martin Gruenewald <Martin.Grunewald@cern.ch> wrote:

> Indeed, as I do not know any G77 internals! Would it be easy to learn?
> Do you have some pointers to start looking?

I'm afraid I have no idea.  I know nothing about g77 either.  In fact,
I know nothing of Fortran :-)

>> you may still help by donating resources to someone who does.

> To whom, what and how?

I suppose you might contact one of the maintainers of g77 directly, or
make an offer at www.cosource.com, or approach one of the companies
that offer commercial support on GCC.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: G77 problem and help needed

[Toon Moene]

Martin Gruenewald wrote:

> Well, no: seeing the error message I tried it on a 256MB RAM and 512MB
> swap system (Linux 2.2), and it still does not compile. In fact, I
> have not found any system on which it compiles, which tells me that
> G77 just uses too much resources for a task which, when done
> sequential when reading the file, should be doable with tiny memory
> requirements.

Yes, that's why we want to fix it in the long run :-)

> Do you have other ideas? A hidden flag to tell G77 not to do anything
> fancy? I tried various combinations of options but without success.

Apparently, the BLOCK DATA file is generated automatically:

CDECK  ID>, WTMXSMP1.
      BLOCK DATA WTMX_SMP1
!     made by  in_file2blkd
!     from src/koralw/data_files/data_wtmax.fit.smp1
      Parameter (LenWTMXSMP1=1739)
      Character*2354 WTMXSMP1_LN(LenWTMXSMP1)
      COMMON /WTMXSMP1 / WTMXSMP1_LN

etc.

Would it be possible to have the program in_file2blkd generate an input
file so that

      Parameter (LenWTMXSMP1=1739)
      Character*2354 WTMXSMP1_LN(LenWTMXSMP1)
      COMMON /WTMXSMP1 / WTMXSMP1_LN
      READ(unit,'(A)') WTMXSMP1_LN

would be sufficient to initialise the array WTMXSMP1_LN ?

Kind regards,

-- 
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
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: G77 problem and help needed

[Martin Gruenewald]

Hello;

On Sun, 25 Feb 2001, Toon Moene wrote:

> Apparently, the BLOCK DATA file is generated automatically:
> 
> Would it be possible to have the program in_file2blkd generate an input
> file so that
> 
>       Parameter (LenWTMXSMP1=1739)
>       Character*2354 WTMXSMP1_LN(LenWTMXSMP1)
>       COMMON /WTMXSMP1 / WTMXSMP1_LN
>       READ(unit,'(A)') WTMXSMP1_LN
> 
> would be sufficient to initialise the array WTMXSMP1_LN ?

There was such an input file in the beginning. Because of some
technical production reasons, the issue is that the program is
supposed to run WITHOUT accessing an external data initialisation
file. Thus, a script was used which transforms the content of that
external data file into a BLOCKDATA routine, this way avoiding the
external file, and having all that is needed to run inside the
executable module.

So, my question: would it be possible to have this fixed soon, ie, for
GCC3.0? Or what is your timescale?


Best regards

Martin


--

Martin W. Gruenewald                   Humboldt University Berlin (HUB)
http://l3www.cern.ch/homepages/gruenew/welcome.html

CERN EP/L3 32-2C07                     e-mail: Martin.Grunewald@cern.ch
CH-1211 Geneva 23                      Phone:  ++41-22-76 79927, 79875, 74477
Switzerland                            Fax:    ++41-22-78 28923

Re: G77 problem and help needed

[Toon Moene]

Martin Gruenewald wrote:

> So, my question: would it be possible to have this fixed soon, ie, for
> GCC3.0? Or what is your timescale?

Well, to tell you the truth: I'd hoped that everyone who complained
about this shortcoming had stopped using g77 ;-)

It's pretty low on my list, because:

1. Only few people run into this limitation.

2. It's a horrible piece of the Fortran Frontend to touch, let alone
   repair.

3. It doesn't silently generate wrong code (which is my definition of
   an urgent bug).

I'm sorry.

-- 
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
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: G77 problem and help needed

[Martin Gruenewald]

Hello;

On Sun, 25 Feb 2001, Toon Moene wrote:

> Martin Gruenewald wrote:
> 
> > So, my question: would it be possible to have this fixed soon, ie, for
> > GCC3.0? Or what is your timescale?
> 
> Well, to tell you the truth: I'd hoped that everyone who complained
> about this shortcoming had stopped using g77 ;-)
> 
> It's pretty low on my list, because:
> 
> 1. Only few people run into this limitation.
> 
> 2. It's a horrible piece of the Fortran Frontend to touch, let alone
>    repair.
> 
> 3. It doesn't silently generate wrong code (which is my definition of
>    an urgent bug).

That's a real pity. Wouldn't it be possible to make the F77 Frontend
just a tiny little bit more horrible, by putting in another if
statement, to make it work?  Something like:

If (compiling_a_block-data) then
  call very_basic_block_data_code_generation
else
  call original_fancy_code_generation
endif

One design goal is surely to compile all legal code...


Best regards

Martin

--

Martin W. Gruenewald                   Humboldt University Berlin (HUB)
http://l3www.cern.ch/homepages/gruenew/welcome.html

CERN EP/L3 32-2C07                     e-mail: Martin.Grunewald@cern.ch
CH-1211 Geneva 23                      Phone:  ++41-22-76 79927, 79875, 74477
Switzerland                            Fax:    ++41-22-78 28923