🚀 go-pugleaf

Return-Path: rdahp!scott@ksuvax1.cis.ksu.edu
Received: from harris.cis.ksu.edu by life.ai.mit.edu; Wed, 12 Apr 89 02:14:33 EDT
Return-Path:  <rdahp!scott@ksuvax1.cis.ksu.edu>
Received: from ksuvax1.cis.ksu.edu by harris.cis.ksu.edu 
		(5.59/SWH-2.03); id AA01040; Wed, 12 Apr 89 01:13:50 CDT
Received: by ksuvax1.cis.ksu.edu 
	(5.59++/CIS1.1) id AA10031; Wed, 12 Apr 89 01:14:44 CDT
Received: by rdahp; Tue, 11 Apr 89 09:56:57 PST
Date: Tue, 11 Apr 89 09:56:57 PST
From: rdahp!scott@ksuvax1.cis.ksu.edu (Scott Hammond)
Message-Id: <8904111756.AA13114@rdahp>
To: ksuvax1!cracraft@wheaties.ai.mit.edu
Subject: Re: GNU CC on a stock ATT System V/386
Newsgroups: gnu.gcc
In-Reply-To: <1558@gluteus.ai.mit.edu>
Organization: R & D Associates, Marina del Rey, CA
Cc: 

In article <1558@gluteus.ai.mit.edu> you write:
>
>Hi,
>
>This letter describes my experiences with GNU CC ("gcc")
>on a stock ATT System V/386 machine (Toshiba 5100).
>
>The system compiler is a pcc-derivative. Compilation
>succeeded with the first Make (as described in INSTALL).
>
>However, upon doing:
>
>	make CC=stage1/gcc CFLAGS="-g -O -Bstage1/" c-parse.tab.c
>
>... the make failed. The symptom of the failure is a lot
>of disk accesses, maybe a lot of compiler temporary-file
>work, and just an infinite suspension of belief.

I had a similar experience.  The machine thrashed for 14 hours on
c-parse.tab.c.  The solution was to compile just that file again with
the native compiler, and then let gcc rebuild the rest of itself (and
disable -O for this pass).  Then you should be able to compile
c-parse.tab.c with gcc (and go around again). 

There is another solution though.  At that time this machine
(386, Interactive's SYSVr3 1.0.4) had only 2 meg, and compiling
the parse file really pushed it over the edge and literally thrashed to
death.  Upon upgrading to 4meg, the same file compiled in a matter of
minutes. 

--
Scott Hammond,  R & D Associates, Marina del Rey, CA  (213) 822-1715
: {ksuvax1,zardoz}!rdahp!scott
:  scott@harris.cis.ksu.edu