Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!flute.cs.uiuc.edu!grunwald From: grunwald@flute.cs.uiuc.edu (Dirk Grunwald) Newsgroups: gnu.gcc.bug Subject: Re: Gnu C Bug (sorta) Message-ID: Date: 6 Aug 89 20:17:24 GMT References: <8908061954.AA09850@voltron.src.honeywell.com> Sender: news@brutus.cs.uiuc.edu Reply-To: grunwald@flute.cs.uiuc.edu Distribution: gnu Organization: University of Illinois, Urbana-Champaign Lines: 25 In-reply-to: guccione@SRC.HONEYWELL.COM's message of 6 Aug 89 19:54:12 GMT We have installed `gcc' on the same configuration (iPSC/2 SRM). If we need to compile from scratch, e.g. if the previous version of `gcc' was buggy or when we installed it first time, we compile everything possible using `cc' (i.e. the greenhills compiler). When that finally died, we compiled the remaining files using `pcc', the portable C compiler. Between the two, they manage to compile everything (eventually). Eventually, we decided to bag it & use cross compilation on an Encore Multimax; the multimax compiles the code to .s files, which are shipped to the SRM and assembled (*sigh* would it be that gas had COFF support). Although the SRM has a reasonable CPU, it is incredibly I/O bound; for some programs (e.g. the inner loop of a parallel prolog byte interpreter that was all one switch statement), the greenhills compiler thrashed the system to death & eventually reported that the routine was too big. Gnu C (on the Encore) managed to compile it, although it *did* take about 20Mb of swap to do it. Thank you FSF.