Xref: utzoo comp.sys.att:6618 gnu.gcc:675
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!umbc3!wolf.umbc.edu!alex
From: alex@wolf.umbc.edu (Alex Crain)
Newsgroups: comp.sys.att,gnu.gcc
Subject: Re: HELP! GCC exhausts 3b1 virtual memory
Message-ID: <2099@umbc3.UMBC.EDU>
Date: 6 Jun 89 17:41:28 GMT
References: <23146@srcsip.UUCP>
Sender: newspost@umbc3.UMBC.EDU
Lines: 30

In article <23146@srcsip.UUCP>, herndon@milo.SRC.Honeywell.COM (William Herndon) writes:

>    suggested.  The compile proceeds smoothly until the cc1 starts work
>    on c-parse.tab.c.  After thinking about it for a few minutes unix
>    complains about virtual memory being exhausted, and the make aborts.

	Try compiling without -O (this works with 1.31)

	This is becoming a serious problem (the size of gcc). Virtual
memory exausted means that you have run out of virtual address space,
a problem wothout a solution. The worst case that I've seen is in gas.
the file m68k.c in gas kills gcc with virtual memory exausted, and
also causes cc to produce bogus assembly code!

	The solution that time was to split the file into two smaller
files and link the objects together (yuuch!) but that won't work with
large bison output because bison output is generally one function
(double yuck!) that can't be split.

	It would be nice if gcc got more effecient, but since the
usually culprit is bison/yacc files, one option is to do an end run around 
the problem and build a bison that would buoid a jump table of absolute
branches, and then compile the individual cases separately as static
functions using common global variables. Kinda gross, but it'll hold us
over until somebody profiles the memory allocation in gcc.

#################################		:alex.
#Disclamer: Anyone who agrees   #    University of Maryland Baltimore County
#with me deserves what they get.#	alex@umbc3.umbc.edu
#################################	alex%nerwin@umbc3.umbc.edu