From owner-freebsd-current Thu May 28 13:47:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22698 for freebsd-current-outgoing; Thu, 28 May 1998 13:47:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22693 for ; Thu, 28 May 1998 13:47:21 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA11840; Thu, 28 May 1998 14:47:04 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA20525; Thu, 28 May 1998 14:47:02 -0600 Date: Thu, 28 May 1998 14:47:02 -0600 Message-Id: <199805282047.OAA20525@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: joelh@gnu.org Cc: nate@mt.sri.com, rnordier@nordier.com, eivind@yes.no, current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object versioning In-Reply-To: <199805282024.PAA01692@detlev.UUCP> References: <199805271551.RAA11565@ceia.nordier.com> <199805281829.NAA01253@detlev.UUCP> <199805281941.NAA20236@mt.sri.com> <199805282024.PAA01692@detlev.UUCP> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> My own concern would be the amount of code in third-party programs > >> that uses gccisms. > > Very few programs *should* use gccisms. If they do, they are broke > > since they won't build on other OS's compilers. > > Not necessarily; ifdef's are common: > > #ifndef __GCC__ > #define inline > #endif So it's a non-issue. > I'm not discussing what should be, I'm discussing what is. We have a > good percentage of software from the Linux camps, and many of their > software authors wouldn't know a non-portable construct if it walked > up and introduced itself in assembly code. Fine, very little of that code is in our tree, including the ports tree. Most of the stuff that matters is commercial and we don't get access to the source and run it under emulation. > >> I guess I don't see why we're looking to change. > > Better/faster/less buggy compiler with a much less restrictive Copyright > > seems like a win overall to me. > > I've seen two compile speed tests and one emitted-code benchmark. So > far, they indicate that while TenDRA normally compiles faster, its > generated code is slower than gcc. The only benchmark was about FPU, and it might not be a problem with the compiler. > I don't know of any bugs in C for gcc 2.7.2.1, and it has a larger > user base to find bugs than TenDRA or XANDF. Finding bugs has never been a problem in GCC. Getting them fixed is the problem. Fixed in the next release was the answer for almost 3 years. :( > In what ways are these other compilers superior to gcc? Faster, smaller, easier to maintain, and re-written. Any software engineer knows that things re-written using the knowledge from previous projects are almost always better than old software that evolves into what it is. The new software is built with the featureset in mind, so it can be better designed into of 'kludged' to support the newer features. This isn't always the case, but it *is* the case when the people doing the work are talented/experienced enough to do things correctly. It appears that the LCC/TenDRa folks are both. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message