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).
If I understand the situation correctly, pgcc is basically a set of patches against egcs/gcc. A lot of the code from pgcc should make its way into gcc eventually, although I believe that some parts can't be included, such as those written by Intel. That's because the copyright for changes to GCC must be assigned to the FSF, and Intel seems unwilling to do so.
"Oh, your 2.2 kernel crashed. Did you compile it with egcs?"
:-/
That is a common question on linux-kernel. Yes, the code was cleaned up in this respect. But nevertheless, noone guarantees you that an egcs compiled kernel will work. I still use gcc 2.7.2.3 on production boxes for kernel compiles.
The difference between egcs and gcc 2.95 is that Mark's aliasing framework is turned on by default. 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
I stand corrected then; than you for the information.
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.
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.
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.
Shouldn't it be trivial (with ispell's "-a" mode) to write a web-based interface to integrate with things like Slash?
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!
Is there any indication from any Important People(tm) when this bug in the kernel will be patched?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Hit the egcs mailing list archives off of the
egcs homepage. There is a long, long collection
of threads about this problem, dealing especially
with the Linux kernel. Linus Himself[tm] gets
heavily involved.
Parts of it turn into a flamefest, but there
/is/ a good deal of information down in there as
well.
In any case, it's not a showstopping bug; you
just have to use a flag.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
C++ is not OO, it's multi-paradigm.
It means that it supports the combined use of classic low-level structured programming (C), object-oriented programming (Simula), and template programming / stronger typing (Ada).
SmallTalk is 100% pure Object. Java is around 75%.
Now, my opinion: C++ is overcomplicated, mostly because it is too low level and high level at the same time.
Compile kernel 2.0 only with gcc 2.7.2; compile kernel 2.2 with -fno-strict-aliasing enabled as a CFLAG in arch/i386/Makefile, and you'll need to edit the configure script for glibc2.1.1 to get that working (and, of course, you need to set CFLAGS=-fno-strict-aliasing with this as well)
I ate something that disagreed with me. Maybe I should have cooked him first.
I think it depends on the project. In some places Java speeds up the process of coding because so much is abstracted. And smalltalk can speed it up even more (although I'd use Java or C++ before Smalltalk), but don't waste your time with "Hello world!" and trivial stuff like that in Smalltalk...
installwatch
gnome rpm work station
I could list more....just go to www.freshmeat.net and search for rpm.
"Gravity must be scholastic occult quality or the effect of a miracle."
You can't get RPM's for this yet, it's just been released! You'll be able to get them when someone makes them, and you'll surely be able to get them at the Rufus RPM Repository. In the mean time, you can try compiling it yourself from the released source. Even better, you can make your own RPM of it, go to RPM.org to learn how (Maximum RPM is a great book).
----
----
Open mind, insert foot.
KAI C++ makes grand performance claims, and Comeau is another compiler built on the same ECG backend (but much cheaper). I'm mainly interested in the Linux platform for now.
Notes:
C++ has it's pros and cons like every other language. Likewise, it is better suited to some applications than others. C++ code can be syntactically cleaner, and more maintainable, or it can be MFC.
It's biggest drawback is that it can obfuscate inefficiencies in code. What looks like a simple assign (or memcpy) can end up serializing and parsing at a high cost.
It may not even be bad coding when the objects are implemented that way (perhaps the 'assigns' are never done in performance critical areas and the marshalling is needed for interoperability.) The problem starts when sombody else has to maintain the code. They end up loosing the advantages of OO code because they either have inefficient code, or have to study the objects and their relationships just as deeply as they would in C.
Personally, I find that by the time I dig through C++ code (for the fabled ease of code reuse) to check for those problems, it would have been just as easy to cut/paste C code. If the objects are available in library form only, it just means that you either end up with wrappers looking like chinese boxes (so that doing anything involves too many pointer dereferences internally), or you end up with a dozen similar objects that all inherit from the same base and do the same thing in slightly different ways.
C++ does have a few nice features. Most of those seem to be in the process of back-porting into the C standard.
Some things call for C++, others call for C, Perl, or Lisp. Some few things even call for assembly.
While it is true you can write OO-like code in C, why would you want to?
In cases where OO is the right approach, but I want to make the cost of various operations quite explicit. The Linux kernal is written that way.
> 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
I don't understand that...
What do you expect?
Should the egcs team hack the compiler to work around "missbehaviours" in the linux sources?!?
Linux that has the problem, *not* egcs. Nearly all other pieces of software (incl. other kernels) compile and work just fine with egcs.
Here
Citation..
(1) Code Fusion produces code that is 85 percent faster than the current Net GNU release, 20 percent faster than the Microsoft Visual C++ 6.0, and equivalent to Intel's Proton compiler. These results are based on the Integer Index performance in the byte benchmark.
<^>_<(ô ô)>_<^>
Oh lord, another language war.
C++ and other OO languages have been proven to be more efficient for programmers on projects larger than 100k lines.
It takes less time for a programmer to start working with a large codebase written in C++ than in C plain and simple.
For example, I was able to make modifications to a bug in Mozilla roughly 20 minutes after I first took a look at the source. When you break your namespace for functions and variables down into peices the way C++ does, it is easier to digest.
While it is true you can write OO-like code in C, why would you want to? C++ is just an extension of C; all the functionality of C is included in C++ at a minimal cost.
--
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
So, has anyone had anyone had any luck getting this to compile with
last1120c or prestruct-c?
What is the performance of binaries compiled with gcc 2.95 compared to that of binaries compiled by pgcc and will the source changes that pgcc has made to egcs be envtually returned to the main source tree?
Cheers
Lucas
Nope, the new_ia32_branch is not folded into
2.95. If you cvs co it its version number is
2.96 right now, but I don't know when the merge
will occur.
When the alias issue came up, Linus told the compiler people to use a set of rules to turn aliasing off, instead of immediately correcting the bug in Linux (it is a bug, because it violates ANSI C aliasing rules, and he was shown at least two ways to fix it.)
That's not good engineering, to write buggy code and expect other people to fix the tools to work around your buggy code.
To compile Linux 2.2x with gcc 2.95, you need to include the flag -fno-strict-aliasing
This flag is needed if you have code that does things like try to read an array of longs as an array of shorts, without using unions.
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.
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.
Will pgcc be merged with gcc, or what is that status of that?
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.
Will it break my system? What are the requirements? Will the kernels compile with it? how about other large projects such as X, Apache, Gnome, KDE.
The compiler is one of the core programs if you don't use binaries so the over-all stability of your Linux box greatly depends on a good combination of compiler, libraries, includes etc etc.
Is there a HOW-TO available on this? (not just saying: "old goes with old and new with new" or providing upgrade instructions for a specific compiler but more a general document describing how some parts of the system work together and how to make optimal use of that)
We tried to ask you, but since you posted as Anonymous Coward we couldn't find you. Since we lacked your enormous wisdom, we, in our lesser wisdom, called it GCC.
We considered the name "gcs". We decided to keep "gcc" because that's the name most people know; had we chosen any name but "gcc" some clueless folks would have kept running gcc-2.8.1 forever. Besides, we'd break every makefile in the world if we changed the name users type.
Don't get hung up on capitals versus lower case. Remember, when you invoke the command "gcc", it will happily build C, C++, Objective-C, Fortran, Java, or Chill for you. So gcc is the GNU Compiler Collection.
Hmmm.... You'd think slash would be integrated with a spel checker by now.
-russ
Don't piss off The Angry Economist