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."
Happy birthday GCC! (Score:5, Funny)
Hey GCC, only one slice of cake for you - you are big and slow enough at the moment (but I love you anyway).
OH NO! It's like I'm married to GCC!
Re: (Score:3)
Codependency destroys families.
Re:Happy birthday GCC! (Score:5, Funny)
yes, you need to resolve ALL dependencies to make it work.
Re:Happy birthday GCC! (Score:5, Funny)
It's best captured in words of that old "Bread" song from the 70s...
"I want to make it with you"
Re: (Score:2)
Given the license used by gcc, "Freedom" would also have been acceptable.
Re: (Score:2)
what? Like this [youtube.com]?
Re:Happy birthday GCC! (Score:4, Funny)
Run off with a young, pretty, thin floosy [llvm.org] instead!
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: (Score:2)
tight,
But the code it generates isn't. With -O3, the majority of time is soent in the optimizer in GCC, and the optimizer is really pretty impressive.
Re: (Score:3)
Just because she got flowered at the Red Carpet at the Oscars does not mean anything's wrong with her or the GCC compiler.
You mean floured [eonline.com], not flowered. Suddenly having her virginity restored while she's walking on a red carpet is a surreal notion, even for Kim Kardashian.
Re: (Score:2)
Re: (Score:2)
Maybe when it can compile F2003/F2008....
Re: (Score:3)
Re:Happy birthday GCC! (Score:5, Informative)
What's all this about GCC being slow? It's one of the fastest (in terms of compile time) compilers I work with regularly. You need to try out some highly optimizing compilers for embedded processors sometime to reset your expectations.
Some real numbers: I just recompiled (with all the optimization bucky bits turned out) my Intellivision emulator and SDK. That's just over 100K lines of code. Took 3.75 seconds with make -j6. "But that's a parallel make!" Fine, I'll do it again tying three of my computer's CPUs behind its back: 13.54 seconds. (Only 8.6 CPU seconds.) At work, it can take 5 seconds just for RVCT (ARM's compiler) just to contact the friggin' license server. Or maybe it's our NFS servers. Hard to say.
Ok, now to be fair, that's nearly all C code. C++ is a whole 'nuther animal. But much of that is C++'s fault, or more correctly the modern C++ libraries. The template processor is a Turing complete functional programming language, if you sneak up on it sideways and catch it off guard. The STL and Boost folks have perfected that snipe hunt and made an industry out of it. That means that C++ code can compile a bit more slowly. (Fine: "a bit" is an understatement. More like a quadword.) BTW, my comment on STL and Boost is not meant to be a flame of their work. It's incredibly useful stuff. But, I consider a bunch of what they're doing something of an abuse of C++'s limited mechanisms. If C++'s metaprogramming facilities were more deliberately designed for this level of use, I think compile times would come down and we'd avoid the "thirty pages of spaghetti because you forgot a comma" error message experience.
The book "C++ Template Metaprogramming [boostpro.com]" has a rather enlightening chapter (Appendix C) on compiler-time performance for various C++ features. (Get a glimpse here. [amazon.com] Just search for Appendix C.) Unfortunately, it's not terribly up to date--my copy says (C)2005--so it measures GCC 2.95.3 and GCC 3.3. GCC definitely was not a performance leader in that era, but most of the compilers were pretty bad. I'd love to see an updated version of it for the latest crop of compilers. I seem to recall finding a website a couple years ago with updated data that showed GCC fixed some of the quadratic algorithms in this space, but I could be dreaming it. If anyone actually has pointers to some data on this, that'd be great.
Pastel compiler? (Score:5, Funny)
Is that some faded-out version of Pascal, perhaps?
Re: (Score:2)
Is that some faded-out version of Pascal, perhaps?
I imagine it was, since he's talking about what happened in 1984.
Pastel and LLNL (Score:5, Informative)
Pastel was an extended Pascal compiler developed by LLNL for the S-1 supercomputer project
http://www.cs.clemson.edu/~mark/s1.html [clemson.edu]
It, and several other significant pieces of software, including the SCALD hardware design language
were made freely available by LLNL. I have one version of the compiler, which was donated to the
Computer History Museum by one of its authors. I have been looking for the other pieces since the
late 80's.
If you look at the GNU Manifesto, RMS was also looking at using the MIT Trix kernel in the early days
of the project.
Measured from where? (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: (Score:3)
Re: (Score:2)
Thanks gcc! (Score:5, Insightful)
You youngin' have no idea of what kind of crap for compilers we had to put up with until gcc.
25 years of compilation with gcc!
Re:Thanks gcc! (Score:4, Informative)
No, it doesn't [lwn.net]. Distributions are evaluating it right now and it is failing big time. Even Xcode developers are pissed off [woss.name] that Apple dropped gcc. That shit ain't fully baked, and imbeciles like you who recite Apple propaganda without thought need to pull your heads out of your asses.
Re: (Score:2, Insightful)
The guy in that second link doesn't sound very pissed off. And clang definitely has WAY better error messages and analysis/refactoring available to it. As for the codegen, it beat GCC by a wide margin when it first came around, but GCC seems to have surpassed it again in more recent versions.
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 insulat
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:Thanks gcc! (Score:4, Informative)
They still do this with GCC. Because of the poor layering, getting a new target often requires hacking up various parts of the middle. Their goal is a working compiler, so they just do the minimum required to get their target working, at the expense of breaking others. These changes won't get incorporated into mainline GCC, so you're stuck with a GCC fork that's going to be unmaintained pretty soon.
Well, back in the past, in the bad old days, they licensed some proprietary compiler and hacked it. You have no idea how good/bad/ugly that was compared to GCC, yet the end results were terrible.
Also, most embedded vendors don't make new CPU architectures. They license existing cores (ARM, PPC, 68k, MIPS) for which GCC already works, making the amount of hackery they need (but not want) to do minimal.
In contrast, LLVM back ends are modular and quite easy to write and, more importantly, don't need to touch any of the rest of the system. This is why ARM is now investing quite a lot in LLVM and companies like Qualcomm have seemingly permanent job adverts for anyone with LLVM experience.
Or, it's because companies love to propritarize stuff because they think that every fart is a "market advantage" nad love to keep totally unnecessary things secret. Like companies that won't even send you a basic datasheet without signing an NDA and other crazy foolishness like that.
Once they get hold of LLVM they won't be able to resist the temptation to stamp on their own proprietary "advatage" at great personal cost to the developers unlucky enough to end up working with thir products. GCC kept them sane by forcing them to admit that their insane and poor quality hackery was worth basically nothing to anyone. This seemed to stop them doing it mindlessly.
I hope, I really hope I am wrong. But, if you've ever suffered under embedded vendors and their desire to stamp their mark for good or bad (usually bad) on their offerings you will understand where I'm coming from: that any method to stop them being idiots and just selling quality hardware is a step in the right direction.
Re:Thanks gcc! (Score:5, Insightful)
How exactly GPLv3 on the _compiler_ stops you from doing anything? It has only one effect: ensures the toolchain stays usable for everyone.
Re: (Score:3)
This could not possibly be more patently false. The use of the GCC compilers has no effect of any kind on the licensing of the resulting output.
Re:Thanks gcc! (Score:5, Informative)
Deliberate misinformation. You are free, of course, to do whatever you want to with binaries produced by GCC. GCC's license is completely irrelevant unless you're modifying or extending GCC itself.
Nice try, though.
Re:Thanks gcc! (Score:5, Informative)
GCC's license is completely irrelevant unless you're modifying or extending GCC itself.
In fairness, Clang and LLVM are designed to be used as libraries and integrated with other projects. Imagine that your favorite text editor uses Clang's own parser to generate its syntax highlighting and check for errors as you type. With the GPL, your editor would likely have to be released under the GPL. Now, I like Emacs so that's not a deal-breaker for me. I can see why Apple and other non-GPL editor authors might not like it, though.
Re:Thanks gcc! (Score:4, Insightful)
Imagine that your favorite text editor uses Clang's own parser to generate its syntax highlighting and check for errors as you type. With the GPL, your editor would likely have to be released under the GPL.
If your editor is modular and you include a plug-in for this function, then only the plug-in needs to be GPL'd. Your program doesn't, because it doesn't depend on it to function, it only adds additional functionality.
Re: (Score:3)
If your editor is modular and you include a plug-in for this function, then only the plug-in needs to be GPL'd. Your program doesn't, because it doesn't depend on it to function, it only adds additional functionality.
I'm not sure. I mean, I get your point and you're likely right. On the other hand, I think you could make a pretty strong case that syntax highlighting in a programming editor isn't additional functionality, but a core part of the editor's basic feature set. I can imagine Apple's lawyers deciding that's a potential vulnerability without a high enough risk-reward payoff to justify using GCC over Clang.
Again, you're probably right. And in the worst case scenario, what real harm could actually come of it? If A
Re: (Score:3)
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?
Re:Thanks gcc! (Score:5, Funny)
No because that would invalidate my unsubstantiated claim.
Re: (Score:3)
This is more handwaving. Let me say it again.
GCC's license has no effect on your source code or your finished binary. It doesn't matter if GCC is GPLv2, GPLv3, or GPLv9. It has no effect. It doesn't matter. It is exactly the same as if it were a proprietary product that you purchased. Better, in a lot of ways, but in no way worse. It doesn't change or affect your license on your final product in any way, and it doesn't require a "legal team" to ascertain that.
LLVM's development has nothing to do with
Re: (Score:2)
Re: (Score:3, Insightful)
Richard Stallman would point out how he has been talking about the dangers of secure boot and software patents for years, and how Theo just now figured out that those things might be a problem. Then we would watch two grown men stare and gleer at each other.
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...
Re: (Score:2, Informative)
clang never beat GCC. The benchmarks clang/LLVM originally published were run against an already old GCC version (by several releases). Thing is, GCC isn't a static target. It keeps getting better, and so far clang/LLVM hasn't been able to keep up.
Same thing with error messages. GCC has vastly improved error messages, now. clang's just look flashier because they use ANSI coloring.
The one place where clang/LLVM has actually managed to keep apace with GCC is in the complexity of the code. While GCC is a macro
Re: (Score:2)
clang never beat GCC.
Really? Let's look at some fairly recent benchmarks [openbenchmarking.org] (from a few months ago). Looks like clang wins some, gcc wins some. The only time the difference is more than a few percent either way is in a test that uses OpenMP, which clang doesn't support at all.
Re: (Score:2)
Two links, one of which is paywalled and the other doesn't support your claim - he's just saying that if you've got code that, for example, depends on GCC's buggy interpretation of C++ template expansion then it may not work with clang and so you need gcc installed too.
And I'm not sure what you mean by Apple propaganda. Apple is one of the companies that uses and contributes to LLVM [llvm.org], but others include Adobe, nVidia, Qualcomm, ARM, MIPS International, AMD, Cray, and a load of universities.
Re:Thanks gcc! (Score:5, Insightful)
Having competing products (browsers, compilers, operating systems, ...) help keep those products from stagnating and help push all involved products to improving. It also helps prevent people being reliant on specific compiler/browser/office suite behaviour. GCC is not a "crap compiler", just like Firefox is not a "crap browser". That is not saying that GCC is issue free, nor that it has improved in part as a result from LLVM/Clang. Likewise, LLVM/Clang is not the panacea of compilers.
Competition on a level playing field is a good thing.
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: (Score:3)
Clang's also not nearly as full-featured as GCC. Cross-compiling is a good example
I'd have to disagree there. With clang 3.0, if you want to cross compile, you do -ccc-target-triple {whatever the target triple is} and maybe --sysroot= {wherever you've put the libraries, headers, and maybe ld and as if your host toolchain doesn't support cross compilation}. With gcc, you need to recompile the compiler for each target architecture you want to support.
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.
That's certainly true. Adding a new back end to LLVM is easier than adding one to GCC, but GCC has the advantage of starting earlier. For
Re: (Score:3)
Always been? Hmmpf. (Score:5, Funny)
Before GCC there were some excellent (for their day) compilers available from what was then an obscure technology company called Microsoft. There were cross-compilers for unusual platforms from Manx Software.
Kids these days. Next thing you know they'll think they invented sex.
Re:Always been? Hmmpf. (Score:5, Informative)
Actually, while PC duffers were futzing with 16 bit Computer Innovations C, Lattice C, Microsoft C 1.0 in 1983, which was pretty much just a ripoff of Lattice C, then through the 80s with Microsoft C 2.0 through 6.0, with the first hesitant entry to 32 bits in 5.0 near the end of that period (even though there was no proper Microsoft 32 bit OS available yet at that time), REAL embedded programmers were working with 32 bit 68000, 68010, and 68020 using Green Hills C and compact deterministic real-time multi-tasking kernels such as VRTX.
Green Hills C was a significant improvement on the Portable C Compiler that came with SunOS and other BSD based unixes in those days.
When gcc finally matured, it was an ENORMOUS boon. The action nowadays is moving to Clang/LLVM though. With Clang, you don't have to compile a separate version for every cross-compile target. Every Clang executable is capable of producing code for any of the supported targets just by using the right run-time options. Of course, this doesn't address the point that you still need appropriate assemblers, linkers,libraries, startup code etc for each target. But they are trying to get a handle even on that with the Clang Universal Driver Project.
Re: (Score:2)
With Clang, you don't have to compile a separate version for every cross-compile target. Every Clang executable is capable of producing code for any of the supported targets just by using the right run-time options.
How is this an advantage? It sounds like it gives you all the disadvantage of a VM (slight slowdown, etc), with none of the benefits (garbage collection, array bounds checking). Why would you not want to compile the binary down to the metal?
Re: (Score:2)
He's talking about the compiler. With GCC, target selection is a compile-time option, so if you want to target (for example) Linux on x86, ARM, and MIPS, you need to compile three different versions of GCC. With clang, you just provide a command-line option to your build and it will generate the code. This is even more important when coupled with something like distcc, which will run the preprocessor on the local machine so you don't need the include files everywhere else, and you can cross compile for a
Re: (Score:3)
You forgot Mark William's C - or was that just Z-80, I don't remember.
At any rate, GCC owes a lot to DECUS C which was donated to DECUS (the Digital Users Group, digital as in PDP-11 digital) by David G. Conroy who wrote the compiler for Dec's RSX11M operating system. He did this when he was at the University of Waterloo and finished it at Teklogix in Mississauga where he and I both worked.
I was the second or third person to use it. Here's a picture of me an Dave at the Teklogix picnic in Terra Cotta. This
Re: (Score:3, Insightful)
Oh, come on. I despise Microsoft as much, or more, than anyone here. But how does freely selling something for an agreed-on price of $75K make SCP a victim, no matter what Microsoft may have done with their purchase subsequently?
If I sell my house for $200K, and the buyer subsequently resells it some time later for $300K, can I be a victim too? Is no one an adult any more, capable of making decisions and accepting the consequences, for better or worse? Let's grow up, shall we?
Re: (Score:2)
And that 1.0 release didn't do pointer arithmetic any better than Lattice did.
Which is to say, it didn't work.
But when we filed bug reports, MicroSoft said it would be fixed in the next release -- which we'd have to buy at full price.
So chalk one up to MicroSoft for conning me out of my rare student dollars to fund their early growth. They never did deliver a working compiler, and I never have forgiven them for ripping me off. And I never will -- I've always looked for the "hook" where MicroSoft is
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: (Score:3)
Actually, gcc is every bit as good for ARM and MIPS as it is for x86.
Re: (Score:2)
Happy Birthday! (Score:2)
Happy birthday (Score:2)
DeSmet C (Score:2)
I still miss putzing around with the compiler from Rick DeSmet to communicate with my dot-matrix printer trying to get it to change fonts. The GCC is a remarkable achievement, and important, but my fondest memories are elsewhere.
Reminiscing (Score:2)
Thank you gnu (Score:5, Insightful)
Now, get off my lawn.
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 !!
It's not just a compiler... (Score:2)
Re:lolcompilers (Score:5, Insightful)
It's hard work being a JavaScript Rockstar. (Score:5, Funny)
Your attitude makes me think that you're not a JavaScript Rockstar. Well I am, and let me tell you, it's not easy being one!
You probably only know Pearl or See Plus Plus or See Sharp or one of those other old hat langs that nobody uses any more. You also probably only write software that's Desktop Scale or maybe even Server Scale. Well that's Old Hat and it's Small Hat!
Us pros, we use JavaScript because it's the best language there is. In fast, it's so good that it's the only one I need to know. It's so fast to work with that I can create five social media applications before you even turn your compiler on! And since I use node.js my web app will scale to the Web And Beyond.
JavaScript has the best dev tools around. I hear that you guys have Visual Studios or something but we have alert(). It's like your Visual Studios but it's a lot more powerful. But we only use it for the Hard Problems because JavaScript makes it so easy to write perfect software. In fact, I haven't created a bug in almost 3 years because JavaScript is perfection and I'm thus perfection because I use JavaScript.
JavaScript is the only option today. If you're not using JavaScript, and only JavaScript, then your code is Old Hat. If your code is Old Hat then you're not a JavaScript Rockstar like me and my colleagues. And if you're not a Rockstar, then you probably shouldn't be talking about programming.
Re: (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
Re: (Score:2)
It is has been intentional been feature ridden....
WTF?
Re: (Score:2, Insightful)
It is has been intentional been feature ridden....
WTF?
I think it's a non-proofread approximation of saying "Javascript has lots of language features, many of which are redundant". The implication being that the language is bigger than it needs to be and so is more complex and difficult to read than it should be.
All ugly languages have this problem, the lack of orthogonality results in massive numbers of anti-patterns (see Perl as the classic default example, C++ is another).
Re:It's hard work being a JavaScript Rockstar. (Score:5, Funny)
<madge>"You're soaking in it."</madge>
Re:I respect the gcc... (Score:4, Interesting)
Re: (Score:2, Informative)
Those were the days before the EGCS fork.
Re:And showing every bit of its age too, apparentl (Score:5, Insightful)
<br><br>
NXP recommends GCC (Code Red IDE which is Eclipse-based), and ST recommends Keil, for their ARM micros. Just FYI.
<br><br>
Good luck on your school project.
Re:And showing every bit of its age too, apparentl (Score:5, Funny)
Good luck on your website.
Re:And showing every bit of its age too, apparentl (Score:5, Insightful)
Re:And showing every bit of its age too, apparentl (Score:4, Informative)
Re: (Score:2)
fuck perceived. show that it works, people will then agree to use it.
I'd reckon a bigger problem is codebases made to compile on specific hard to get versions of say.. arm rvtc.
if the problem for using gcc is just perceived bloat in binaries you're in heaven, stfu and eat cookies.
Re: (Score:2)
Happy birthday gcc - making me think more carefully and write better code for 25 years!
beg to differ (Score:4, Informative)
You can have the best algorithm in the world, and a good compiler will *still* be able to make it run faster than a bad one.
Alignment, branch probabilities, inline functions, hoisting stuff out of loops, loop unrolling, removing unused code, etc.--these sorts of things really can make a difference in code that gets called frequently.
That said, it's not exactly clear that the Intel compiler (icc) is unconditionally better than gcc. There are some benchmarks at http://www.linuxforge.net/docs/bm/bench-gcc-icc.php [linuxforge.net] of a linux-2.6.34 kernel compiled with gcc and icc. The results are close enough that it doesn't make sense for most people to use icc.
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: (Score:2)
It doesn't support C99 very well (at all?), it doesn't allow inline functions, forces you to declare all your variables at the top of a function, and a number of other annoying things that I only remember when I have to use it.
This can be concisely summed up as "doesn't support C99", really, because all other things that you list are the consequence of that. When VC is compiling in C mode, it can be very pedantic about being a C89 compiler - heck, it doesn't even support // comments then. About the only thing you have from C99 is stdint.h.
For all intents and purposes, it really is a C++ compiler, with C support being more or less a legacy feature.
Re: (Score:2)
Re: (Score:2)
The way things are, basically, 90+% of native code written for Windows is C++ and not C - and hence C++ gets priority. And there's plenty undone in that department as well, particularly now that C++11 is out - VC++ has a few cherry picked features from there since v10, but it's starting to lag behind GCC now, and needs to catch up fast. Those precious few dev resources the core compiler & library team gets, they throw at C++ again to move ahead of schedule - e.g. they didn't originally intend to impleme
Re: (Score:2)
Anyway, range-for loops are good too. But let's be honest, is there any reason a company with Microsoft's resources can't keep up with gcc?
Re:And showing every bit of its age too, apparentl (Score:5, Informative)
True, but adding // comments would take 10 minutes (assuming you know the code), and giving the ability to declare variables wouldn't take long either.
You forget about all the associated red tape. Even a minor feature has to be tested, and some QA ultimately has to sign off for that. It also has to be documented by tech writers, complete with code samples, and said documentation to be translated to all supported languages (I believe over a dozen now for VS). Any associated user-visible output (e.g. new errors/warnings) also has to be proof-readed and translated. It all adds up.
But let's be honest, is there any reason a company with Microsoft's resources can't keep up with gcc?
It can, if that were the goal. But the ultimate goal is to earn money, same as for any other for-profit company. Hence, things aren't done because they are neat or the Right Thing or because everyone else has them. They're done because the expected profit from the feature - whether direct (from sales of the product) or indirect (from sales of other products propped up by the SDK, like, say Windows) - exceeds expenses. Even more importantly, resources being large but still limited, for every feature the question is not whether it is profitable in and of itself, but whether it is more profitable than something else that could be implemented in its place. It's that stack ranking that really kills C99 support - there's always something more important (read: more profitable).
Of course, people aren't cogs, and sometimes they feel hard enough about something - purely out of the desire to do the Right Thing - that they play bureaucracy games to come up with a plausible "business case" for their favorite cause, and ultimately convince the management that calls shots to let them put it in. But, there's no-one there who feels hard about C99 (or at least harder than a dozen other things that need to be done first, preferably yesterday - like, say, variadic templates...)
Re: (Score:2)
Re: (Score:2)
Is GCC on Windows still treated like a third-class citizen? I remember a resistance to supporting certain features of Windows that the MS computer supported like SEH but I dont know if that has changed.
Re: (Score:2)
Re: (Score:2, Insightful)
Well, one thing that's happened to me an awful lot is that GCC seems to generate smaller *and* faster code when using -Os rather than -O3. That it'd be smaller was no surprise to me, but the speed-up was. (For reference, I'm using an IA32 2 GHz CPU with 1.5 GB of RAM.)
Fewer cache misses, maybe?
Re: (Score:3)
Re: (Score:2)
Depends largely on the size of your cpu cache, although i was pretty sure gcc (or maybe it was some other compiler) had some options to take cache sizes and relative performance of different level caches vs ram into account when generating optimized code.
Re: (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
Re: (Score:3)
Unless of course clang generates code that is twice as slow as gcc
SmallPT [kevinbeason.com] is one graphics program that seems to be much slower with clang than gcc.
Re: (Score:3)
As the other poster pointed out, clang does not support OpenMP. If your code uses OpenMP, then this is a very serious limitation. It means that your code will execute on a single thread with clang, but on multiple concurrent threads with gcc. If your program doesn't make use of OpenMP, then this benchmark is highly misleading.
Oh, and if your code does use OpenMP, the odds are that Path64 will be significantly faster than gcc.
The other poster mentioned blocks. I just did some work on Solaris support in
Re:And showing every bit of its age too, apparentl (Score:5, Informative)
Are you an Apple shill in your spare time?
I'm trying to read this thread, and I have to put up with your repetitive posts about how great clang is. Why don't you read some of the replies [slashdot.org] to your crap? They do a good job of debunking your claims. I have mod points, but I just hate moderating people down, even if they waste my time repeating unfounded assertions (also known as bullshit).
Re: (Score:3)
LLVM/Clang is a very interesting project, it's sad it's gaining traction because of GPLv3 haters/fanboys/etc. and not because of its qualities. I fear their actions might even harm it, i.e. users and developers could stop being interested in it being the better compiler as long as it's "more open" (lol).
Re:OH GOD HELP ME (Score:5, Funny)
Remove the "\n" from your printf statement. After you graduate, make sure to tell the interviewer you want the management ladder.
Re: (Score:3)
puts() will, actually.
Re: (Score:3)
No, no, no. This is a HARD PROBLEM. You MUST use RECURSION!
void print_string(char *string)
{
putchar(*string);
print_string(string + 1);
}
Re: (Score:2)
Re: (Score:3)
Long live GCC, IMHO the major reason why we no longer pay for compilers as we used to.