GCC 4.0.0 Released 680
busfahrer writes "Version 4.0.0 of the GNU Compiler Collection has been released. You can read the changelog or you can download the source tarball. The new version finally features SSA for trees, allowing for a completely new optimization framework." The changelog is pretty lengthy, and there's updates for every language supported from Ada to Java in addition to the usual flavors of C.
Moving fast (Score:4, Interesting)
Re:Moving fast (Score:5, Funny)
Re:Moving fast (Score:5, Funny)
Re:Moving fast (Score:3, Funny)
Re:Moving fast (Score:3, Funny)
'Cause we (the people who find you funny, insightful and interesting) are pasty couch potatoes just like you.
Re:Moving fast (Score:3, Funny)
"And next time I get mod points, you will also be overrated, redundant, flamebait and a troll."
Re:Moving fast (Score:3, Funny)
Done.
Re:Moving fast (Score:3, Funny)
Re:Moving fast (Score:5, Interesting)
Re:Moving fast (Score:3, Informative)
GCC 4.0's biggest winner is probably KDE (Score:5, Informative)
Re:GCC 4.0's biggest winner is probably KDE (Score:5, Informative)
-a GNOME/KDE agnostic fluxbox user
Re:Moving fast (Score:5, Interesting)
Re:Moving fast (Score:3, Insightful)
GCC is pretty much the standard for the industry.. there are faster, and more specialized, but GCC is the standard.
Linux/Unix/BSD/etc, IBM, servers, clients, embedded platforms, all hosts of different computers.
Hell if you just look at the embedded computers there are more of those then all the different desktop computers (Windows + *nix + Apple) put together.
Re:"Paltry" is probably a poor choice of words (Score:5, Insightful)
Unix and its children and cousins on the back and front end probably double the total number of apple boxes out there. If not more so. Hell some numbers suggest that there actually are more linux desktops than mac desktops. Even if its close between apple and linux on the desktop (which is likely) the number of nix systems in use in general at least matches the number on either side (though they are not desktops).
Re:"Paltry" is probably a poor choice of words (Score:3, Insightful)
My concept of numbers is probably fine. Try this, desktops dwarf servers and such. So your 50% of a small number is not all that meaningful.
Re:"Paltry" is probably a poor choice of words (Score:5, Informative)
Mac OS X itself is compiled with GCC 4. That was the point. Hence, all Mac users depend on GCC 4. That's 40 million and counting according to the latest figures.
Re:Moving fast (Score:3, Informative)
in terms of technology, SSA is far more important as it optimizes "the big picture".
Re:Moving fast (Score:4, Insightful)
However, I was referring to the underutilization of Altivec in G4/G5 environments. Whereas SSA will be excellent across platforms, autovectorization will be especially significant on chipsets with powerful vector processors.
Being able to optimize for this hardware, which is not as common or powerful in the x86 world, without much effort is indeed significant.
I do not disagree with your assessment in the relative worth of SSA and vectorization, but I would simply like to clarify my post.
Lisp? (Score:4, Funny)
Re:Lisp? (Score:5, Informative)
Re:Lisp? (Score:5, Funny)
From A to J. Lisp starts with an L.
Therefore, according to the summary... no.
Re:Lisp? (Score:5, Informative)
Yes, gcl (formerly known as kyoto common lisp). But it doesn't need the assembler/linker part of the toolchain so it's packaged separately. But I think it is "Part of the GNU Compiler Collection", for what that's worth, and it does depend on GCC.
i'm having horrible flashbacks... (Score:4, Interesting)
Why? (Score:5, Funny)
Did you not get pleasure out of things being errors in 3.0 that weren't even warnings in 2.95?
I'm sure all the contractors loved it! ;)
GCC motto: "What code can we break today?
Misplaced blame (Score:5, Insightful)
Did you not get pleasure out of things being errors in 3.0 that weren't even warnings in 2.95?
At least the maintainers of the ISO C++ standard did.
GCC motto: "What code can we break today?
Blame the standards committee, not the GCC maintainers.
Re:Misplaced blame (Score:5, Funny)
Insightful? Jesus eff-ing Christ. Now the slashbots don't like standards. I bet you wouldn't be presenting the same argument if this discussion was about the transition from MSVC 6.0 to 7.0/7.1.
Re:Misplaced blame (Score:4, Insightful)
Personally, I prefer GCC to be standards compliant.
Re:Misplaced blame (Score:4, Funny)
Funny? Jesus eff-ing Christ. When did pointing out the hypocricy of slashdot group think become funny? I don't get which part of my original statement is funny.
Re:Misplaced blame (Score:5, Funny)
Customer: Thanks for fixing it so quickly!
Mechanic: We didn't fix it. We just brought it up to standards. Oh, by the way, your air conditioning no longer works, and your rear brakes are now disabled.
Customer: Uhh.. What?
Mechanic: That's right. The standard refrigerant is now R-134A, so we removed your old R-14 air conditioning system. Also, disc brakes are now standard in the autmotive world, so we removed your drum brakes. Don't drive too fast.
Customer: What the fuck?
Mechanic: Oh, I almost forgot. Your car doesn't have airbags. We're going to have to remove your car's body and replace it with a giant tube frame lined with air mattresses.
Re:Misplaced blame (Score:5, Insightful)
Re:Why? (Score:5, Insightful)
Standards are the reason that computers are tolerable to use for any purpose.
If a programmer can't be bothered to follow an international standard of his own language, there is no guarantee that the code is future-proof. One can hardly blame the compiler vendor, as we can't expect a compiler to mindlessly maintain backwards compatibility with every weird use of a bug and every bizarre code construct that has ever been supported in the past.
The ability to compile code written for GCC in another compiler is a *good* thing. If it requires informing the programmer that their code has always been broken, then so be it. A little inconvenience is a small price to pay for standards compliance, or should we expect that the GCC authors "embrace and extend" C and other languages until so much code relies on weird GCC nuggets that programmers (and users) are "locked in" to using just that compiler? (But Douglas Adams forbid if Microsoft does the same thing!)
Maybe I am missing something. If so, please enlighten me (This is not a sarcastic remark--I haven't done much research on what 4.0 has broken so I may be way out of line).
Sheesh, for as hard as the GCC authors work, and for as much GCC has improved in the last 10 years, the contributers sure get a lot of flak. Anyone who doesn't contribute code themselves should be greatful (or at least appreciative) of their efforts, even when they do make mistakes.
Re:i'm having horrible flashbacks... (Score:3, Interesting)
In the long term, I think it was a very good thing: coding C (and C++, but didn't have that much experience on that) got much more stickt and in my experience, removes a lot of possible problems later on.
If someone had a lot of problems porting 2.95 to 3.2, his code needed to be reveiwed anyway. It kind of removes the "boy" from "cowboys" in coders (experience is drawn f
Re:i'm having horrible flashbacks... (Score:4, Funny)
Which results in..... cows
Re:i'm having horrible flashbacks... (Score:3, Funny)
I'm hoping for a mutation into GNUs
Is anyone else curious what SSA trees are? (Score:4, Interesting)
Re:Is anyone else curious what SSA trees are? (Score:4, Interesting)
Re:Is anyone else curious what SSA trees are? (Score:5, Informative)
Re:Is anyone else curious what SSA trees are? (Score:4, Informative)
Re:Is anyone else curious what SSA trees are? (Score:5, Informative)
To put it simply, SSA is an intermediate representation where each variable in a block is defined only *once*. If a variable is defined multiple times, the target of any subsequent definitions of the same variable is replaced by a new variable name.
SSA helps to simplify later optimizations passes of a compiler (for example: eliminating unused definitions, etc) as described in greater detail (with examples and flowcharts) in the article linked to.
That's the SSA form in short. Now I need to ask somebody the difference between the standard SSA form and "SSA for trees".
Re:Is anyone else curious what SSA trees are? (Score:5, Informative)
Trying to recall my knowledge of optimizing compilers:
SSA makes optimization easier, since it is obvious where a variable was assigned (since it was assigned in only one location) and what value it contains (since there is only one value being assigned to it). The complexity moves to register allocation, where there can be many more variables to allocate because of SSA. Register allocation is Hard, but doing an ok job is quite possible. Most optimizations are impossible unless you can prove various properties about the variables involved, which is often much easier with variables in SSA form.
Re:Is anyone else curious what SSA trees are? (Score:5, Informative)
Hmm. Funny. Seems like perfect timing, in retrospect. I just held a presentation on SSA (and efficiently transforming code into SSA) today.
Get the slides here [udel.edu].
HTH
Re:Is anyone else curious what SSA trees are? (Score:5, Informative)
1) Tokenize the input. For example, if you were compiling perl, you might choose to turn "print $foo" into three tokens; KEYWORD_PRINT, TYPE_SCALAR, and IDENTIFIER('foo'). The output is typically a stream of tokens. This step might be done by lex or flex.
2) Parse the sequence of tokens using a set of rules called a grammar. For example, "TYPE_SCALAR" followed by "IDENTIFIER()" is might match a rule to generate a variable called "$foo", and "KEYWORD_PRINT" followed by a variable means call the function print on the contents of the variable. The output is typically an abstract syntax tree (AST); a high-level data structure representing the program. This step might be done by yacc or bison.
3) Match the AST against a series of rules to output the final code. This might actually be two steps; you might generate something into a low-level register transfer language (RTL) that looks very much like assembly, and then turn THAT into actual machine instructions.
At each stage, you might choose to optimize the output. You might also insert optimizations passes between steps. (For example, you might insert a pass between 2 and 3 to optimize the AST into a simpler AST.)
Before SSA, GCC sort of skipped making any high-level AST; it used to go from parsing almost immediately into a RTL. You can still optimize RTL, but since it's pretty low-level, it misses out on higher-level context and made some optimizations really difficult.
SSA is simply a form used for the high-level AST. Why SSA? It is a very nice form to optimize. Read the wikipedia article for more details on why SSA is particularly useful for some optimizations.
Page 181 of this PDF file [linux.org.uk] from the 2003 GCC Summit explains the flow of the GCC compiler.
Sweetness (Score:5, Informative)
debian (Score:5, Funny)
Re:debian (Score:5, Insightful)
Re:debian (Score:5, Funny)
Re:debian (Score:3, Interesting)
Kidding aside, no. Debian is legendary for being, ahem, slow about releases; they release when it's done, not on some date. Thus
If GCC 4.0 made changes that would affect the ability of the linker to link things, then GCC 4.0 would actually be slow to go i
Re:debian (Score:3, Informative)
As Debian sid is the unstable branch of Debian, the release cycle is pretty unimportant for gcc's inclusion. Looking at the experimental branch, you'll find gcc 4.0 already included: http://packages.debian.org/experimental/devel/
(
In sid itself exists a snapshot of gcc as of 20050319.
Re:debian (Score:5, Informative)
whoa (Score:4, Interesting)
also, the c++ side makes me feel optimistic about ongoing support, which had been a big problem till 3.4.
yes im x86/64 centric.
Re:whoa (Score:4, Interesting)
Actually they do just that. You put a #pragma omp before a for loop to have it implemented using threads. You put another #pragma omp before access to a shared variable to have access serialized. You never code to a specific API. The compiler automatically generates pthread calls, Win32 calls, etc as appropriate. Your code is portable. Lawrence Livermore has some nice examples but the seem to be down right now, www.llnl.gov.
works great! (Score:3, Funny)
NO CARRIER
Re:works great! (Score:3, Funny)
NO CARRIER"
So... what.. did you have FireFox open while trying to compile it?
Re:works great! (Score:4, Funny)
-foxxz
Re:works great! (Score:5, Funny)
It doesn't always get modded fun&@^4-- NO CARRIER
Trees (Score:4, Funny)
So I guess its pretty safe to say that this release is for the birds
*ducks*
Autovectorization (Score:5, Interesting)
Re:Autovectorization (Score:4, Informative)
Fedora Core, for example, relies on the improved instructions for atomic operations found in 486 and newer processors, necessary for certain threading libraries. The rpm program itself requires a 586, if I don't remember wrong.
Fedora Core also compiles all binaries optimized for P4. It was decided to use P4 optimizations, since these generally work just as well on Athlon processors, while Ahtlon optimizations is rather slow on a P4.
Furthermore, for CPU intensive applications such as many audio and video applications, CPU optimizations such as MMX and SSE are automatically activated at runtime if the CPU supports it.
The 'i386' in the name should really be called 'x86'. Of course, then there's also 'i686' packages, which basically mean 'x86 processors that support the CMOV instruction'. That is also wrong, as there are i686 processors which do not support CMOV, such as certain VIA and Cyrix variants.
CMOV is basically the only useful addition to the x86 instruction set since the i486 for general purpose programs. And programs not fitting into that category, already have hand written asm for time critical sections, which can take advantage of MMX, SSE, 3DNow, Altivec or VIS.
vectorization very rarely works (Score:5, Insightful)
Without automatic vectorization, the performance benefit of compiling for 686 as opposed to 386 is simply minimal. A lot of people have done benchmarks on this, and found out that tuning for 686 with gcc only provides 1-2% improvements in the best case. Keep in mind that current X86 processors execute instructions out-of-order, so instruction scheduling for a specific pipeline is not going to do much (it's very important for in-order machines, though)
Re:vectorization very rarely works (Score:3, Informative)
> and found out that tuning for 686 with gcc only
> provides 1-2% improvements in the best case.
Uh what? It is true that i386 code runs in the ballpark on a Pentium IV, but this most definitely was not true for the Pentium III and is not true for the Pentium M. Those processors have the 4-1-1 rule, which is to say that you'll stall concurrent execution of instructions unless you arrange a complex instructions (4) with two simple ones (1). This is be
Re:vectorization very rarely works (Score:3)
I was talking about gcc, and gcc alone. After all, this is a story about gcc 4.0. I'm very well aware that compilers like icc are more capable of exploiting differences between old processors and newer ones. It's just that gcc is not. Please show me one single benchmark -- from a respectable suite, not something concocted to prove a point, and not something that has inlined assembly -- where tuning for 686 in gcc gives more than 5% performance improvement! My very strong belief is
Re:Autovectorization (Score:4, Interesting)
Right in some ways, but importantly wrong in others. Red Hat and the Fedora Project, for example, are compiled using the i386 instruction set but optimized for i686. This means that the cmov instruction isn't available -- but apparently, it's not much of a win (and even a loss in some cases) on modern processors. And code which uses SSE or 3DNow or whathaveyou is usually carefully hand-coded and checked for at runtime.
There's not really much advantage of switching away from this scheme, so I don't see it as worth the bother. Instead, x86_64 will eventually kill it all off and we'll move on to that.
Re:Autovectorization (Score:3, Interesting)
Re:Autovectorization (Score:5, Interesting)
Re:Autovectorization (Score:5, Informative)
Also, there aren't nearly enough people using MOVNTDQ to avoid polluting the instruction pipeline and dumping useless garbage into the system cache. If you're copying stuff into main memory and you aren't going to use it for a while, use MOVNTDQ to get a big speed win. If you do need it cached, use MOVDQA to get both caching and 128 bit transfers in one instruction! We all paid for these fancy schmancy new instructions in our processors, and it's extremely annoying to see programmers not use them.
Figured this had to happen (Score:5, Interesting)
Re:Figured this had to happen (Score:5, Informative)
Well, you're wrong because GCC doesn't follow Apple's schedule, or anyone else's for that matter. Even a cursory glance at the GCC mailing list will tell you that.
The reason Apple can promise this is that they're not actually shipping GCC 4. They're shipping their own fork of the GCC 4 code. It's probably about 99% the same code, but don't make the mistake of thinking they're shipping exactly what the FSF is distributing.
Re:Figured this had to happen (Score:4, Interesting)
We're not shipping "a fork" of GCC 4. We're shipping GCC 4.0.0, which we compiled from source for Darwin 8.
In fact, when you're talking about shipping a compiler for a specific platform, the whole notion of "a fork" is basically meaningless.
(Setting aside, of course, that the whole notion of "a fork" runs 100% counter to all that open-source stuff that you guys are supposedly so hip to anyway.)
Re:Figured this had to happen (Score:5, Informative)
According to http://gcc.gnu.org/install/specific.html#powerpc-
i.e. you're using a forked version of GCC, and definitely not 4.0.0 out of the box.
the whole notion of "a fork" runs 100% counter to all that open-source stuff
No, actually, the importance of the ability to fork and wisdom to know when to fork is very important to "that open-source stuff".
Re:Figured this had to happen (Score:4, Interesting)
*chuckle* (Score:5, Funny)
Compatibility? Linux testing? (Score:4, Interesting)
Just about every time I have to rebuild a kernel or build a kernel mod I get my butt kicked by gcc versions. So my questions are?
Anyone know?
Re:Compatibility? Linux testing? (Score:5, Informative)
Readme.SCO (Score:5, Interesting)
The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible aggression against free software and GNU/Linux. We have decided to take no action at this time, as we no longer believe that SCO is a serious threat.
For more on the FSF's position regarding SCO's attacks on free software, please read:
http://www.gnu.org/philosophy/sco/sco.html
Re:Readme.SCO (Score:4, Interesting)
gcc -v on Fedora 4 test 2 (Score:4, Informative)
Using built-in specs.
Target: i386-redhat-linux
Configured with:
Thread model: posix
gcc version 4.0.0 20050405 (Red Hat 4.0.0-0.40)
Re:gcc -v on Fedora 4 test 2 (Score:5, Funny)
> gcc version 4.0.0 20050405 (Red Hat 4.0.0-0.40)
aren't they supposed to release a broken 3.96 first???
how much java comaptibility (Score:4, Interesting)
Something fun with compiling... (Score:5, Funny)
Objective-C++...? (Score:4, Interesting)
Re:Objective-C++...? (Score:4, Informative)
Fact is, demand for Objective-C++ from our developers is so close to zero as to be completely insigificant. Seriously, there's more demand for Python than Objective-C++. Honest to God, Python!
All the ISVs who are still using C++ are building their apps with Core Foundation, not with Cocoa. That's fine. Core Foundation is a first-class application platform in Mac OS X. It's just so much more of a pain in the ass to use, developers are flocking away from C and C++ to reimplement in Objective-C, not even bothering with Objective-C++ along the way.
So it's not that we don't have the time. It's that we don't see the point.
Re:Objective-C++...? (Score:4, Interesting)
No they're not! And I myself am not about to port hundreds of thousands of lines of C++ code to Objective-C since that'd eliminate the Windows version, which I can't do!
In the code base I'm currently porting to Cocoa, all of the application's core logic and data structures are written in C++, and the user-interface layer is written natively for each platform. So the Mac version gets a high-quality Cocoa front-end and Windows/Linux/BSD gets a wxWidgets front-end (since wxWidgets does a good job on those platforms).
Take away Objective-C++ (and therefore Cocoa C++) support and I'll just compile the wxWidgets version for the Mac since CoreFoundation is, as you say, a pain in the ass to use. The result: another low-quality "Windows-app-in-Aqua-clothing" Mac app.
Cross-platform toolkits, such as wxWidgets, SWT and Swing produce usable but low-quality Mac applications (missing sheets, drawers, collapsable toolbars, AppleScript support, and so on and so forth). Objective-C++ allows me to easily write high quality Aqua-compliant applications easily. So if Apple values Mac users it will keep supporting Objective-C++!
Not to mention that, for me at least, Cocoa/C++ is one of the reasons I use a Mac in the first place. I can produce professional user interfaces in no time and still know that I can port the core logic to Windows/Linux/BSD.
Oh, and I'm working in the games industry, where the majority of code is C++. I know for a fact that Apple wants more games code ported to OS X.
Screenshots? (Score:5, Funny)
Re:Screenshots? (Score:5, Funny)
just when OpenBSD i386 started to move to 3.x (Score:3, Interesting)
OpenBSD i386 is finally moving towards gcc 3.x, as the bugs have been cleared up even if the performance regressions haven't. I'm wondering if 4.x will be even worse, and if it will be justified by producing better binaries. From TFA, it looks like they've added a few features that may improve optimizations. If it's noticeably better they may move to the new version faster.
I will have to play with it to see what it can do.
Patent issues (Score:5, Informative)
They mean this patent [uspto.gov] owned by this company [microsoft.com]. What a surprise.
Getoo forum thread on gcc 4 (Score:4, Informative)
Shouldn't they have done this 10 years ago? (Score:5, Interesting)
One _ancient_ compiler (10+ years) I have to use, already has this feature -- and on a large scale: it'll do it over several screensful of code. What took GCC so long?
Unfortunately, this compiler I mention also has a bug: once it's factored out 'i' in a piece of code like that below, it then complains that 'i' is an unused variable. So you have to do something with 'i' to suppress that warning, which kinda defeats the purpose of the autovectorization.
Sample code:
int a[256], b[256], c[256];
foo () {
int i;
for (i=0; i256; i++){
a[i] = b[i] + c[i];
}
}
Example (Score:4, Interesting)
Notice the lack of an array index. These are true vector operations to begin with, so it is already assumed that the array elements are independent, therefore the log and addition can be parallelized safely.
TR1 included! (Score:5, Informative)
MINGW? (Score:3, Insightful)
So, any ideas of how long till the MINGW port is done?
Re:Great Timing (Score:4, Informative)
Re:Testing the old girl out... (Score:4, Informative)
FYI: Red Hat has a guy working full-time on building OOo on GCJ. His blog. [linux.ie]. Not that everything works straight out-of-the-box. But it's not like nothing works either.
(And from what I've heard, you can't expect it to work out of the box either. Sun's coders have done a terrible job and adding all kinds of dependencies on undocumented Sun-internal classes. So it probably doesn't work on Apple's JDK either, and that one is Sun-approved!)
Re:What a coincidence (Score:5, Informative)
While it is true the syntax has changed (much for the better: templates are now supported in managed C++ code and so are generics, keywords replace ugly __gc, and more), support for the old syntax is still in the compiler (/clr:oldSyntax), and IntelliSense.
However, you will be unable to mix new syntax and old syntax code in the same project without taking some penalties (IntelliSense will break, at the least). The designer will even spit out old syntax code when designing an old form or control.
While the old syntax is definitely on its last legs, the VC++ team was very concerned about not screwing over those (early) adopters of C++ code for the CLR thus far.
A good resource to read up more on the subject would be Herb Sutter's Blog [msdn.com], Stan Lippman's Blog [msdn.com], or any of the other VC++ team member's blogs.
Take this from a former VC++ teammate who left during the Whidbey product cycle (posting AC since I've never bothered to get a slashdot account).
You're right. (Score:3, Informative)
The different languages ARE separated into different compilers.
Re:stupid dumb moronic question (Score:4, Informative)
Does all this extraneous language support make gcc bloated for single-language compilation?
Short answer: No.
Long answer: pretty much every compiler around goes through the following steps: (a) make an abstract syntax tree from the source code, (b) optimize it, and (c) output machine code. No matter what language you're using, these steps must be performed; a multi-language compiler simply provides many ways of doing (a). But since optimization happens after (a) anyway, it doesn't matter.
That's oversimplifying, since if a compiler were tuned to a single language it could probably use a slightly simpler abstract syntax tree format. But the benefits would be slight; it's far more useful to support tons of languages at little extra effort than to drop all alternate languages for a minor performance gain.
people use -fweb (Score:3, Informative)
So the choice has been:
- -O2 -fweb
- -O3 -fno-inline-functions
(adding -frename-registers or -fno-rename-registers too, as desired)Re:Pascal (Score:3, Informative)
GNU Pascal supports building with a number of versions of GCC, and work on GNU Pascal is with a released version of GCC. The GCC developers want GNU Pascal as just another frontend; changes should go to GCC head, and there shouldn't be #ifdefs to get it to compile with different versions of the compiler backend. That's a large problem that has stopped GPC from being merged.
Re:No hope for named warnings (Score:4, Informative)
Maybe I'm missing something, but this warning is GCC telling you that it's not going to compile that code.. so you can't possibly "need" it because GCC doesn't even compile it.
uint8_t i=0;
if (i>300)
{
printf("hello");
}
Compile that, and then see for yourself.. strings a.out | grep hello will return nothing. gcc optimizes your useless check right out.