Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!mintaka!jtw From: jtw@lcs.mit.edu (John Wroclawski) Newsgroups: comp.unix.aix Subject: Re: GNU C,G++ for RS/6000 Message-ID: Date: 6 Jun 91 20:13:39 GMT References: <389@arbortext.UUCP> <7749@spdcc.SPDCC.COM> Sender: news@mintaka.lcs.mit.edu Distribution: na Organization: MIT Home for Wayward Triumphs Lines: 25 In-Reply-To: rbraun@spdcc.COM's message of 6 Jun 91 17:49:47 GMT In article <7749@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: From: rbraun@spdcc.COM (Rich Braun) Date: 6 Jun 91 17:49:47 GMT The Free Software Foundation has stated in no uncertain terms that the RS/6000 won't be supported until gcc version 2.0 comes out, which is obviously months or years in the future (this is due to a spat between IBM and the FSF; IBM is worried about "contaminating" its code with copylefted sources, so it refused to make some FSF software available to its customers--that's how I remember the episode). Say what? I'd imagine the primary reasons for not supporting the RS/6000 in gcc 1.x are a) gcc1 doesn't have the ability to do instruction scheduling for superscalar processors well, while gcc2 does, and b) gcc2 is close enough that it doesn't make a whole lot of sense to put effort into a gcc1 port, specially given that gcc2 will be able to generate much better code for this particular machine. Once long ago IBM decided to not ship gnu emacs with a product after saying they would because the folks who sell another emacs claimed, in the interim, that gnu emacs used some of their code. In fact, Stallman appears to have had permission from the original author of that code to use it; in any event the code in question since been completely rewritten. None of this past history has anything to do with gcc.