GCC 4.0.0 Released
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.
Is it just me or did the jump from version 3 to 4 happen a lot faster than the one from 2 to 3?
Coder's Stone: The programming language quick ref for iPad
Yeah, but does it have a Common Lisp compiler yet?
of the 2.95 -> 3.0 transition.
Not a C coder myself, (sticking mainly to perl).. I've just got to ask, what are SSA trees, and what benefit do they serve?
da w00t. mtfnpy?
Glad to see they are targeting the AMD64 architecture for improvements.
i wonder when debian sid will integrate GCC 4.0...
reading tfa and changelog intrigued me. optimisations aside im curious if this will be better able to thread on the new multi-core systems coming out, as tls has been spotty till 3.3 and glibc 2. maybe native xd support coming soon too?
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.
The first rule of USENET is you do not talk about USENET.
I've already downloaded it and used it to recompile Firefox and I must say that gf@fd@k3nl&
NO CARRIER
Unknown host pong.
So I guess its pretty safe to say that this release is for the birds
*ducks*
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?
Correct me if I'm wrong here, but most Linux distributions are still i386 right? It's only the people who use Gentoo who actually compile everything with i686 options right? So, if autovectorization and all the other improvements in GCC 4.0 make binaries massively faster on modern platforms, how long will it be before the major binary based distributions (like Ubuntu) start making i686 the default and i386 an available alternative (like AMD64 is now).
How we know is more important than what we know.
When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.
I can see my Gentoo box sweating now all nervous for the night I get a little drunk and decide to see how this gcc 4 thing works out. heh heh heh.
It's not a snapshot though, it's a fork (from that date). Apple has done some development on it.
Why didn't the poster just link to a list of mirrors? I don't want my favorite compiler's source to be unavailable =(
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?
XML is a known as a key material required to create SMD: Software of Mass Destruction
I can't wait to figure out what will (won't?) build with GCC 4.0.0. (One thing's for sure... JDK and OOo won't.)
FYI: Red Hat has a guy working full-time on building OOo on GCJ. His blog.. 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!)
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.
Fedora Core 4 has literally been waiting for this.
From Feburary: http://lwn.net/Articles/124798/
That article includes the question/answer:
- Does that mean Fedora Core 4 will ship with a pre-release compiler?
We're not *that* crazy. If GCC 4.0 is delayed, we will either revert, or slip.
Tharkban (It is a signature after all)
Hurry up and download your copy now, before the price goes up!
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
% gcc -v
../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --host=i386-redhat-linux
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)
i am interested in the java compatibility. i figure it probably won't do swing, but will it support, or is will it do say gtk/java native. that'd be sweet. i know Qt/kde has had a java bridge for a while, but i really haven't played to much with it. flame java all you want, it's not a geek language. no obfuscated java, no java monks. BFD. sure that'd nix the whole write-once run anywhdere thing. but hell, what a great opportunity to build and test apps under a jre then compile them, to native.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
and no gentoo users commenting on how they've already recompiled their entire system with the new optimizations. Or maybe they're just waiting for some free resources to open a browser.
They've been talking about having Objective-C++ in the GCC main branch for years now. There was even talk that 4.0 wouldn't ship without it. Now it's shipped without it and it's still "coming Real Soon Now". Any word on if it's coming any time soon (really)?
...but it's being eaten...by some...Linux or something...
The parent poster is refering to the deprecation of Managed Extensions for C++ syntax in favor of C++/CLI (which is undergoing ISO standardization).
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, Stan Lippman's Blog, 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).
Screenshots anyone? ;)
The OpenBSD crowd had a lot of concerns about bugs in 3.x and performance regressions (in compiling, not in the resulting binaries). I believe Linus shared some of these concerns (don't have a link handy).
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.
I rarely criticize things I don't care about.
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)
The Raven
Sure, OpenOffice.org spends a lot of time at the idle loop compared to say Half-Life, but there are some cases when even a word processor can lag. Faster loops make repeated operations on the most complex documents, such as Writer reflow, Calc recalculation, and Draw repainting, faster. Faster operations make OOo more responsive in general. More responsive OOo makes users happy.
due to the fact that all its c++ shared libraries will now be 40% smaller due to the symbol visibility improvements (i.e., no runtime adjustment needed by the linker for internal-only functions). This translates into a significant speed improvement for all KDE code.
Does anybody have some informal performance benchmarks between 4.0.0 and the last version? (particularly the runtime of the application)
They mean this patent owned by this company. What a surprise.
For those who want to know what works and what doesn't: http://forums.gentoo.org/viewtopic-t-176085.html
Are there benchmarks comparing 3 to 4 available? What benefitw would the average user eventually expect from this release? Thanks!
-- IV
http://www.LinuxMedNews.com Revolutionizing Medical Education and Practice.
As I understand it - and I'm sure someone will correct me when I'm wrong - gcc is actually a suite of language-specific "front ends" which reduces a given language to a common intermediate form that is then compiled(and linked, etc) by the "back end" into the executable code. In a way you already have different compilers... they're just all grouped together in one package.
I'd rather be flying
The different languages ARE separated into different compilers.
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.
So the choice has been:
- -O2 -fweb
- -O3 -fno-inline-functions
(adding -frename-registers or -fno-rename-registers too, as desired)One of the changes in 4.0.0 is autovectorization optimizing.
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];
}
}
That game was gold. And I too wish you could shoot the dog.
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.
Escher was the first MC and Giger invented the HR department.
Will named warnings never be impemented? Or numbered? Something that lets me turn off a warning for a particular line of code?
Have you ever tried writing an overflow safe integer class? I have, and I did, but I have to compile everything with -w because otherwise I get 40 pages of "condition will always be false due to limited range of data type". Bleh! If it will always be false, throw it away! I need the check in there for when the type will be a signed int.
Does anyone have a ray of hope? I love most of GCC's warnings, and have always been able to work around them, but in this case there's just no way to get rid of them.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
You have no concept of numbers. Both Linux and mac are minor on the desktop but close to 50% of the backend of the internet is handled by unix or unix like systems (not including apple). The vast majority of which use gcc or some derivative.
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).
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
You have no concept of numbers. Both Linux and mac are minor on the desktop but close to 50% of the backend of the internet is handled by unix or unix like systems (not including apple). The vast majority of which use gcc or some derivative.
;-)
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.
Gentoo has had a GCC 4 ebuild for months now. I've been using it to build my system. If you really really want it, you need to set your package.keywords to -* and also unmask it in package.unmask.
Then be prepared to switch between gcc 3.4 and 3 a lot because many packages, especially multimedia packages, fail to build.
Something that I would really like to see integrated into GCC, sooner or later, is GNU Pascal.
They always seem to be close, yet it never happens.
Let's say that Apple has 99.9999999% of all desktop installs. Even then, almost none of them actually use GCC.
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.
From what I've read, GCC 4 is blazingly fast, _AND_ provides dead code elimination (VERY important for windows users).
So, any ideas of how long till the MINGW port is done?
Cheers,
Ian
I think that stuff like this made the GCC developers to add de -pedantic flag, from de man file:
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++.For ISO C, follows the version of the ISO C standard specified by any -std option used.
Valid ISO C and ISO C++ programs should compile properly with or without this option (though a rare few will require -ansi or a -std option specifying the required version of ISO C).However, without this option, certain GNU extensions and traditional C and C++ features are supported as well.With this option, they are rejected.
-pedantic does not cause warning messages for use of the alternate keywords whose names begin and end with __.Pedantic warnings are also disabled in the expression that follows "__extension__".However, only system header files should use these escape routes; application programs should avoid them.
Some users try to use -pedantic to check programs for strict ISO C conformance.They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all---only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added.
A feature to report any failure to conform to ISO C might be useful in some instances, but would require considerable additional work and would be quite different from -pedantic.We don't have plans to support such a feature in the near future.
Where the standard specified with -std represents a GNU extended dialect of C, such as gnu89 or gnu99, there is a corresponding base standard, the version of ISO C on which the GNU extended dialect is based.Warnings from -pedantic are given where they are required by the base standard.(It would not make sense for such warnings to be given only for features not in the specified GNU C dialect, since by definition the GNU dialects of C include all features the compiler supports with the given option, and there would be nothing to warn about.)
"pendantic" is a ironic way of call it.
>Linux is not user-friendly.
It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
Is broken in some important ways, for example you can't pass complex numbers to functions, which is why it isn't the default
I am trolling
??? When an application calls fork() everything that happens next is up to the kernel. The definition of fork() is that the child gets an identical copy of everything. What does the compiler have to do with this?
-- *My* journal is more interesting than *yours*...
Does this new GCC have a transparent background?
Mac OS X itself is compiled with GCC 4.
Amazing, considering it was just released. Maye Jobs has missed his true calling as a purveryor of time machines?
That someonebody is me. Yes, the binaries from 4.0.0 compared to 3.4.3 are very very.
No. Being the largest single vendor is not the same as being larger than all other vendors combined. Apple may be larger than RedHat, and larger than Mandrake, and larger than Slackware, and larger than Debian, but that doesn't make Apple bigger than all of them combined.
Infuriate left and right
It's not supposed to fork the file pointer.
Read data in from a 'while()' statement and store it into an array. When it reaches a certain size, fork the process, kill the array and start filling it up from STDIN. Next time you fork your data is partially duplicated in Solaris and not at all duplicated under Linux.
The backend of the internet compared to the number of desktop machines? Talk about having no concept of numbers.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
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.
No, no, and no, jackass! Max OS X Tiger was compiled with gcc 4. Hence all Mac users do not depend on gcc 4. That is not 40 million and counting...it is currently zero. Give it a rest!
Given a choice between free speech and free beer, most people will take the beer.