This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: gfortran 4.3.2 running out of memory on a file
On Fri, Nov 07, 2008 at 04:49:36PM -0800, Tom Epperly wrote:
> Steve Kargl wrote:
> >On Fri, Nov 07, 2008 at 04:14:35PM -0800, Tom Epperly wrote:
> >
> >>Steve Kargl wrote:
> >>
> >>>On Fri, Nov 07, 2008 at 03:57:15PM -0800, Tom Epperly wrote:
> >>>
> >>>>I've got a situation where gfortran is running out of memory, and I am
> >>>>wondering if there are any guidelines that would help me change my
> >>>>source file to get it compiling. I am working with code produced by
> >>>>source code generators, Babel http:// www. llnl.gov/CASC/components/
> >>>>and Forthon. I am attaching a reproducer.
> >>>>
> >>>>f951: out of memory allocating 1352 bytes after a total of 2766893056
> >>>>bytes
> >>>>
> >>>What does ulimit show and how much memory does the machine have?
> >>>
> >>I am normally a tcsh user, so here is the tcsh equivalent followed by
> >>ulimit. I assume that cat /proc/meminfo will provide enough details
> >>about the machine's memory situation.
> >>
> >
> >Well, I killed the compile with top(1) showing
> >
> > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
> > COMMAND
> > 5612 sgk 1 119 0 7923M 7184M CPU1 0 7:50 98.63% f951
> >
> >A quick look shows
> >
> >troutmask:sgk[228] grep -i " use " bbb_Mod_Impl.F90 | wc -l
> > 20194
> >troutmask:sgk[229] wc -l *.mod
> > 86254 total
> >
> >gfortran does not currently cache a read module. So it will faithly
> >read and store whatever information appears in the *.mod each time
> >it hits a USE statement. The autogenerators prolific use of modules
> >and the 138k LOC are too much unless you have a real big system.
> >
> >
> Is there any likelihood that gfortran will start caching read modules in
> the near future? If I have "use sidl" 700 times in the source file,
> will gfortran dutifully store 700 copies of the internal presentation
> corresponding to the contents of sidl.mod? If yes, I have no prayer of
> getting this thing to compile unless I can dramatically reduce the
> absolute number of "use" statements. It seems to me that caching read
> modules would have benefits to normal Fortran files in additional to
> abnormal ones like bbb_Mod_Impl.F90
AFAIK, no.
bbb_Mod_Impl.F90 is simply a collection of subprograms. It
looks like you can split it into smaller chunks. The first
10K LOC takes 5 GB to compile (and this is without turning
on optimization).
--
Steve