GCC 2.95 Released

sparky writes "The GNU Compiler Collection (GCC) 2.95 is available ."> here [Ed: Please use a mirror]. This is the first release of GCC since the EGCS steering committee took over, and a major step on the way to GCC 3.0. " Interesting to see we have a new ANC (acronym name change).

Comments

Re:Kernel and GCC 2.95

[Anonymous Coward]

There have been some heavy debates about this on the kernel mailing list and apparently the communication between the egcs team and Linus was not very successful :-/

Linus is a great guy and all that. But he has some blind spots. Among them are Quality and Engineering issues. He just does not have the background or experience to make good judgements in these areas. He lacks a humility which would tell him that he is not an expert in all areas of computer science. What we are starting to see is that his lack of expertise in some areas has hindered Linux's ability to scale well across architectural and performance bounderies. In other words, the kernel is becoming more and more complex and Linus is unfamiliar with the technologies which could address these issues. And worst of all, he appears to be unwilling to learn.

Re:Sterring. Rhymes with herring.

[Jonas �berg]

I'd recommend browsing Slashdot with Lynx and using Emacs or some other
such editor to edit text inputs. It's all very sweet because using an
external editor makes it so much easier to run ispell.

GCC and Ritchie's compilers

[ajs]

It's great to see the full span of history, here. The previous article was Ritchie releaseing code for the first C compilers and this one is GCC 2.95 which is the culmination of at least 15 years of work on the part of Stallman, FSF, Cygnus and probably tens of thousands of volunteers. For those who are looking to advocate Open Source within their companies, or just see for yourself what this "new" paradigm can produce, please read the GCC source! It's some of the best code I've ever seen (though I admit it has it's... blemishes). The way it achives platform neutrality while producing highly platform-optimizied code is genius, and you can really feel its roots (the intermediate language is a compromise between Stallman's love for LISP and a desire to keep compilation fast and efficient). This is all without going into the fact that there are now front-ends for every major programming language with the exception of the purely interpreted ones (Perl, Python, TCL, etc).

Currently, as far as I am aware, this is the finest compiler on the face of the Earth, and I dare someone to prove it wrong. There are compilers that produce faster code for a specific platform, and there are compilers for languages that GCC has never heard of, but GCC wins the all-around best technology (IMHO) for producing native instructions from your pet language. It's the one tool which I feel justifies all of Stallman's quirkiness, and gives me faith in the future of Open Source.

Re:GCC and Ritchie's compilers

[JoeBuck]

As a member of the gcc/egcs steering committee, I would be very happy if, in fact, GCC were "the finest compiler on the face of the earth". It isn't. It is the most widely ported compiler, and it's decent enough, but many other compilers beat it for code quality.

gcc 2.95 still isn't that great on Intel-compatible processors. The good news is that we finally have a new IA32 back end, produced by Cygnus under contract, that has been donated; we'll finally have enough accuracy to do instruction selection and scheduling properly. It will be in gcc 2.96 (or whatever we call it). Until then, pgcc will be better (I believe that the new back end beats pgcc at least most of the time).

Re:Ada kernel

[Scurrilous Knave]

Ada95 supports OO programming, but unlike, say, Smalltalk, it doesn't restrict you to that model. You are correct that an Ada kernel would be easier to maintain, and yes it would be more portable--at least in my experience, Ada is more portable not only between platforms, but between compilers, than C, and even moreso than C++. The "not as efficient" is a myth. One can write inefficient code in any language. Real efficiency comes from choosing your algorithms wisely--a warrior thinks of tactics, a good warrior of strategy, but a great warrior thinks of logistics. And besides all that, since an Ada compiler has more information than, say, a C compiler, about what the programmer actually wants, it can make better decisions and actually generate more efficient code, especially for today's pipelined multiple-functional-unit CPUs. Not that GNU Ada necessarily does better than GNU C, but in practice the efficiency question is a red herring.

I applaud the fact that you didn't just blindly flame what you do not know. I would suggest that you learn a bit about it--who knows, you might like it!

Thanks

[Anonymous Coward]

Since nobody here have really said it I want
to say thank you to all developers that spend
their time making gcc better.

I use gcc/g++ almost every day and I am very pleased with it.

Web pages

[Jonas �berg]

Now then, before anyone comes bursting in saying that we havn't updated the web pages: look again. I just updated the web pages on www.gnu.org and I hope that the steering committee will update their web pages on gcc.gnu.org soon too. It's the idea that eventually the web pages from gcc.gnu.org will magically appear att www.gnu.org, possibly with some small stylistic changes, but we havn't gotten around to this yet.

As a blatant plug I'd also like to say that the GNU Webmasters need more help. Do write me if you want to help out.

Kernel and GCC 2.95

[Kento]

I was just reading the linux kernel mailing list (which i *just* resubscribed to) and apparently, the kernel won't compile correctly with gcc 2.95. Here's an excerpt:

The linux kernel violates certain aliasing
rules specified in the ANSI/ISO
standard. Starting with GCC 2.95, the gcc
optimizer by default relies on these
rules to produce more efficient code and thus
will produce malfunctioning
kernels. To work around this
problem, the flag -fno-strict-aliasing must be
added to the CFLAGS variable in
the main kernel Makefile.

Disclaimer: I haven't downloaded the new compiler and so I haven't tried it yet, but keep this in mind when you upgrade gcc.

Re:Kernel and GCC 2.95

[sterwill]

I understand how easy it is to criticize Linus from behind the security blanket you call anonymitiy, and I can't disagree with all your points, but I'm not sure you understand Linus's position (perhaps you understand it better than I). The kernel tree is very large, and I wouldn't want the job of coordinating all the development that goes on within. Just reading the linux-kernel mailing list is a job in itself.

I admire the job Linus is doing but I can't imagine a single person doing it any better. I've always found Linus a humble guy in the end. Show him something's really better your way, and in a way he can understand (considering the other work he does), and often he'll adopt it. He's made an occasional policy or kernel decision that might have upset me, but coordinating public devlopment can be acurately described as herding cats. It's an endless series of tradeoffs because everyone wants to go his own way; sometimes patches are rejected, sometimes the ideas they implement become the center of rabid e-mail debate, and sometimes they're quietly applied.

The sheer numbers of developers and different directions and goals of each pulls on Linus in a different direction. I've used Linux on a variety of architectures, and I wish Linus would focus more on keeping 'stable' release of the kernel clean across all architectures--these are the quality issues of which you speak. 2.2.10, for example, won't compile on an Alpha.

I can't say I see Linus holding back the performance of the kernel for reasons of stubbornness. Most of the performance improvement suggestions he receives present a risk in other areas (stability, security, portability). He's making trade-offs, and I personally admire most of the decisions he's making.

Scalability and performance issues are most often encountered when trying to make the Intel architecture do something it was never intended to do: be scalable. I think it's unfortunate that so many people continue to squeeze this twenty-year-old idol of cruft into such places when cleaner and better engineered alternatives exist.

I think he's doing a very good job.

Re:Kernel and GCC 2.95

[Kento]

The 2.0 kernels used illegal inline assembly constructs which just happened to work with GCC 2.7.2 . You could always compile the 2.2 kernels with whatever compiler you wanted. From what I can tell, this is different, and it affects all kernels, including the 2.2 ones.