GCC Turns 25 192
eldavojohn writes "With the release of GCC 4.7.0, the venerable and stalwart constant that is the GNU Compiler Collection turns twenty five. More ISO standards and architectures supported with this release and surely more memories to come from the compiler that seems to have always been."
Measured from where? (Score:4, Interesting)
Re:I respect the gcc... (Score:4, Interesting)
Re:Measured from where? (Score:5, Interesting)
EGCS stands for Experimental/Enhanced GNU Compiler System. It was a decendant of GCC which used a more open development process. This meant that it included more optimizations and language features than the standard GCC.
This experiment was very successful, and version 2.95 of GCC adopted the EGCS code. Since then GCC has been developed using the same methods as were used for EGCS.
For more information and the official announcement (now historical) see this page and the GCC homepage.
When you have a project fork, like egcs, that gets folded back into the main branch (or even when it becomes the main branch), then the main branch gets to hog all the credit and claim that it was its idea the whole time.
So gcc is and always has been gcc, even when it was egcs. :P
Re:Pastel compiler? (Score:0, Interesting)
Hoping to avoid the need to write the whole compiler myself, I obtained the
source code for the Pastel compiler, which was a multi-platform compiler
developed at Lawrence Livermore Lab. It supported, and was written in,
an extended version of Pascal, designed to be a system-programming
language. I added a C front end, and began porting it to the Motorola
68000 computer. But I had to give that up when I discovered that the
compiler needed many megabytes of stack space, and the available 68000
Unix system would only allow 64k.
Re:Happy birthday GCC! (Score:4, Interesting)
I've actually been tempted to have a fling with TCC [bellard.org].
Small, tight, flexible, low maintenance and can do the business just about anywhere.
Re:Always been? Hmmpf. (Score:5, Interesting)
Indeed, for most of gcc's existence I always saw it as a reasonable lowest-common-denominator compiler, not an especially good one. Up until about a decade ago, "cc" almost always beat "gcc" in performance on any given UNIX, but every "cc" was so different (especially if you dared throw C++ into the mix) you had to virtually port your code to each one. gcc was available for everything and had a reasonable percentage of the standard implemented so was where everyone gravitated towards. Since egcs merged back in and linux has gone more mainstream with Android variants it's gotten a lot more attention and is finally a pretty decent compiler.
Re:Thanks gcc! (Score:5, Interesting)
Err... no?
Clang can be faster than GCC, when compiling with no optimizations. When you compile with optimizations enabled, that advantage disappears. Despite being nearly as slow as GCC with optimizations enabled, the binaries it produces are often slower. Some code (usually code that benefits from optimizations that Clang's developers could implement more easily than GCC's developers) may be slightly faster when compiled with Clang, but GCC's optimizer is far more mature than Clang's, and generally works better.
Error messages... Can't argue there. Modularity is pretty cool too, especially when you can built other tools on top of Clang that use Clang's parsers. Nothing stopping you from using those tools with another compiler though.
Clang's also not nearly as full-featured as GCC. Cross-compiling is a good example. Clang supports only a very limited number of architectures, and even with a supported architecture, cross-compilers are still kind of clumsy. Sure, GCC isn't perfect at this either, but you can use GCC to build code for virtually any platform that's still in use, and almost every platform that's been in use in the last 20 years, on nearly every operating system.
On most of the platforms GCC supports, it's by far the best compiler available. In some cases, it's the only compiler available. Even if the Clang developers wanted to support such a wide variety of platforms (they don't), it would take years to even approach GCC.
Even for things like C++11 support, GCC is still ahead. Despite Clang being apparently easier to develop (better architecture, or whatever), GCC has such a huge head start on Clang that it's managed to support far more of the new standard than Clang. It supports more of it than Microsoft's compiler too (which I gather has an architecture similar to Clang, but grew from an architecture that more closely resembles GCC).
Basically, Clang's a great compiler, but it's still very new. It's developed amazingly quickly, and I think it's going to be a fantastic compiler in a few years, but it's not quite there yet.
Re:And showing every bit of its age too, apparentl (Score:3, Interesting)
RTFM idiot - Os means to optimize for size. The generally accepted standard flag for GCC is -O2 as it's the best compromise between Size and speed up. The only thing is, Sped Up is dependent upon various elements within the source code such as loops and CPU specific options as we Gentoo users tested. Some apps actually do well with O3 flag, most work fine with O2 and from my experience, Os offered the best performance with smallest size possible from the binaries. Most of the speed increases come from fewer cache misses as the binaries are sometimes small enough to actually fit within the L2-L3 cache when the cpu has sufficient space.
Re:Thanks gcc! (Score:5, Interesting)
But the key for any commercial entity is that clang beats the pants off any GPLv2-licensed compiler, and GPLv3-licensed code is pretty much irrelevant to most applications. So GCC is doing a great job for the insulated linux world, and hopefully clang can catch back up to offer the rest of us a better choice.
God, I hope not, I really do. I remember the bad old days, especially with embedded vendors. They would livense a perfectly good compiler front end and then fuck it up beyond repair. The resulting steaming heap of shit would crash half the time, and mysteriously not support random language features.
Ever since GCC took over the compiler world, my life has been much better.
Experience says that if you give vendors the chance to screw up a compiler in the name of "business" or "propretary" or whatever then they will.
Re:It's hard work being a JavaScript Rockstar. (Score:2, Interesting)
I know your joking and I think I can smell sarcasm even but you are not helping our cause one bit.
JavaScript as a language is not the problem it can be used wisely. It is has been intentional been feature ridden and with the state of the browser wars going on anything complex is a security risk. The browser wars have also probably left it with the worst development tools known to man.
Don't even get me started complaining about how every site doesn't work because it uses JavaScript, and that is sent as raw code on every request unless you pull magic tricks to combine, minify, compress and CDN serve.
It's a retarded misuse of an okay idea and just begs for every thing to break with it's modern day usage.
Re:And showing every bit of its age too, apparentl (Score:4, Interesting)
Basically stay away from Microsoft compiler for C if you can help it.
Re:Thanks gcc! (Score:5, Interesting)
This is just fearmongering. It's not complicated at all. If you don't hook GCC's (internal) intermediate code generation to run some custom process on, then you are covered by the compilation exemption.
Configuring your build to output GCC intermediate, retain that output, modify it with an external tool, and resume the build with the modified intermediate code is not something that will happen by accident. The implications of GCC being GPLv3 are, exactly, none.
FreeBSD's philosophical objections to GPLv3 are well known and they have the right to maintain those objections, but that has little bearing on GCC's use for a proprietary end product.
I would be interested to hear about your build process that you feel is likely to accidentally create a non-exempt compilation. Do you have an example?
Theodore Ts'o yay (Score:5, Interesting)
Linux started on usenet, and what really made it blow up was the ability to use gcc to write software. The first version of linux everyone was running didn't have a login, you just got root. Soon the login program came, (i think getty). But anyway it was Theodore Ts'o who did the heavy lifting. Every new program needed something new in the C library and Theodore somehow got it done.
Thanks Theodore !!
Re:Thanks gcc! (Score:5, Interesting)
The FreeBSD project has already declined to upgrade its GCC implementation to the GPL version 3 release.
With my FreeBSD developer hat on:
The reason that we have not upgraded to GCC 4.3 or later is not that we fear GPL contamination of resulting binaries. In fact, we're working on external toolchain support that will allow you to build FreeBSD with the gcc 4.7 from ports if you want. The problem is that FreeBSD ships a complete UNIX system, and the Single UNIX Specification requires a C and C++ compiler. Lots of downstream users want to take FreeBSD and distribute derivatives of it. Many of these have a no-GPLv3-anywhere-in-the-company policy. This is because distributing GPLv3 code may inadvertently license some of your patents. Even if you think abolishing software patents would be a good thing, just licensing yours to everyone while your competitors don't is not a very good strategy...