Date: Thu, 28 May 1998 17:01:00 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: nate@mt.sri.com 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 Message-ID: <199805282201.RAA00542@detlev.UUCP> In-Reply-To: <199805282047.OAA20525@mt.sri.com> (message from Nate Williams on Thu, 28 May 1998 14:47:02 -0600) References: <199805271551.RAA11565@ceia.nordier.com> <199805281829.NAA01253@detlev.UUCP> <199805281941.NAA20236@mt.sri.com> <199805282024.PAA01692@detlev.UUCP> <199805282047.OAA20525@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> 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. Not if I want inline code. >> 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. Matters? Matters to whom? The only commercial app I myself run is Allegro. >>>> 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 was actually thinking of the grep that ran twice as slow. I will agree that we have few data points to go on. Unless somebody has some *data* for me, I think I'll go off and make some data points. I'm setting up a simple benchmark. Admittedly, benchmarks aren't that terrific, but it's what I've got availible. I'd like to get information from everybody... What compilers do you want me to test? And where can I get their sources? Email me privately, and I'll try to benchmark your favourite 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. :( I'm aware of the hassles with gcc under AIX, but I haven't run into any with 2.7.2.1 under FreeBSD. Admittedly, I haven't looked for bugs, but I haven't had problems. Again, I am presently referring to C, not C++ or Objective C. >> In what ways are these other compilers superior to gcc? > Faster, No data yet. Point me at data, or point me at sources so I can make some. > smaller, Nice, but with today's hardware, smaller for the sake of being smaller is less and less of a factor. I'm all for reducing bloat, but not at the expense of performance. > easier to maintain, Can't speak to that, haven't tried. > 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 feature > set in mind, so it can be better designed into of 'kludged' to > support the newer features. I totally agree. But I'd like to see feature set, and the speed. > 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. Okay. I'll take your word for it. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805282201.RAA00542>