Mark Mitchell announced the availability of GCC 4.0.1, officially released on July 7'th. He explains, "this release is a minor release, containing primarily fixes for regressions in GCC 4.0.0 relative to previous releases." GCC 4.0.0 was released two and a half months ago on April 20th, as seen on the official release timeline. A list of bug fixes in 4.0.1 can be found here.
GCC is the GNU Compiler Collection which includes C, C++, Objective-C, Fortran, Java, and Ada compilers. Download GCC 4.0.1 from a gcc.gnu.org mirror.
From: Mark Mitchell [email blocked] To: gcc, [email blocked] Subject: GCC 4.0.1 Released Date: Fri, 08 Jul 2005 00:48:37 -0700 GCC 4.0.1 has been released. This release is a minor release, containing primarily fixes for regressions in GCC 4.0.0 releative to previous releases. http://gcc.gnu.org/gcc-4.0/changes.html#4.0.1 This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.0.1 subdirectory. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery, LLC [email blocked] (916) 791-8304
| How to make my PCIE ATA storage device running in Linux | 3 hours ago | Linux general |
| sata/ide timeout errors on asus server-mb | 6 hours ago | Linux kernel |
| Shared swap partition | 7 hours ago | Linux general |
| usb mic not detected | 11 hours ago | Applications and Utilities |
| Problem in Inserting a module | 12 hours ago | Linux kernel |
| Treason Uncloaked | 18 hours ago | Linux kernel |
| high memory | 3 days ago | Linux kernel |
| semaphore access speed | 3 days ago | Applications and Utilities |
| the kernel how to power off the machine | 3 days ago | Linux kernel |
| Easter Eggs in windows XP | 3 days ago | Windows |
Good, but...
GCC is now 4.0.1, which means one step closer towards stability. But how long until we can start migrating to it en masse? Should we really think of it as the latest DEV branch and wait until 4.1.0 to move?
Upgrading compilers is not like dusting crops. One false move and you can compile yourself into oblivion...
Good but...
Personally I would consider GCC 4.0 useful mainly to compiler writers with a few exceptions (people interested in vectorization). Right now GCC is going through a series of internal changes as the old RTL optimizers are removed and their jobs replaced by the new tree-ssa stuff. However, the 4.0 and 4.1 releases currently have both optimizers and there are still many, many cases where (at least for the architectures I deal wiith) code is pessimized by having both optimizers.
The debate still seems to be out as to removing the RTL optimizers completely. There probably are advantages to having RTL optimizers even when the tree-ssa stuff is working as effectively as possible; but the RTL optimizers will have to be tuned for the new middle-end.
I think that 4.2 is where the new GCC optimizer framework will really start to pay off. One advantage of 4.x right now though is improved compile speed, especially for C++; but some of us have to target pitiful hardware and optimization is a requirement for successful operation (sadly, I'm in this boat).
There are some really good things to look forward to in the coming GCC 4.x series though. 4.1 will have IBM's stack-smashing protector merged. This could be a serious feature for server software.
-MYG
Re: Good but...
The parent poster is selling nonsense.
Two points of fact:
1) It is not really IBM's stack smashing protector, but an almost completely new implementation of the idea, done by RedHat. IBM's implementation was never in an acceptable shape. The guy at IBM working on SSP was told so many times over, and he didn't want to fix it. So someone wrote a new implementation of the idea. Credit where credit is due, so in this case to RedHat.
2) The RTL optimizers are not being removed at all at the moment. Very few are scheduled for removal, too. Most of them will just stay, but perhaps in a simplified form. No RTL have been replaced or even just turned off by default in GCC 4.1 (except maybe the recently removed -fforce-mem, which was not enabled by default at any level of optimization anyway).
Oh, and GCC 4.0 is already production quality. Why do you think all major linux distributions are using it in their next product line? You don't have to wait for GCC 4.1 or even GCC 4.2. GCC 4.1 will have a lot of new tree-ssa passes and a framework for interprocedural optimizations (with a few optimizations implemented like side-effects analysis and constant propagation). GCC 4.2 will probably have more of that, and a rewrite of alias analysis for tree-ssa. But those are all just enhancements. GCC 4.0 is ready and works now.
Please make sure you download GCC 4.0.1 though. GCC 4.0.0 has some pretty nasty bugs lurking in it.
GCC4 may be ready, but accord
GCC4 may be ready, but according to the only published benchmark I've seen, the code it produces is clearly inferior to GCC3. That's probably what the poster meant, not if it just works but if it's better than the previous version.
" the code it produces is cle
" the code it produces is clearly inferior to GCC3. "
AFAIK, this is not true.
Some optimizations in GCC4 indeed produce better results.
Sometimes GCC3 is better. Some GCC4 binaries are bigger
some are smaller. It seems to depend very much on the
source (type and language).
For "modern" C++ code doing templates all over gcc 4 is
clearly the better choice.
ac
especially the error reportin
especially the error reporting in gcc 4.x is far better for templating errors
mg
not production quality!
Why do you think all major linux distributions are using it in their next product line?
This frustrates me a lot. I see that none of the distributions that I as a developer find "major" are actually using gcc-4.x as their _default_ compiler. As a matter of fact, _none_ of the available source distributions is using gcc-4 at all, and most are still using gcc-3.3.
The reason for this is a sickening lack of interest of the gcc, glibc and kernel developers to provide the community with a set of tarballs that actually compile against each other. For three years now this is degrading the adoptance of gcc-3.4 and gcc-4.x and driving us distro packagers crazy.
The "major" distros you are talking about must have tens of skilled glibc hackers working for them to patch glibc to compile, but anyone else other than redhat is in the dark: Even the glibc crew advises people _not_ to use a CVS glibc, but that's the only source of fixes.
We're all spinning circles here around glibc and gcc, not to mention the twangle of kernel headers. Please don't call gcc-3.4+ production quality.
Re: not production quality!
Fedora Core uses GCC4 as the system compiler. My understanding is that Gentoo is moving also. SUSE will have GCC4 as the system compiler in their next products too, but that is not a source distribution of course. And Debian... well, Debian... *sigh*
On the 7th a prerelease of gc
On the 7th a prerelease of gcc 4.01 was already in Debian unstable, which is good enough for me. I still wish for udev and xorg, though :)
Udev is available
Udev has been available in unstable for quite sometime. Xorg... well good point.
http://packages.debian.org/unstable/admin/udev
Re: Udev is available
udev is in stable too, has been in sarge at least six months before release.
xorg
X-Org has been uploaded to unstable!
See here:http://www.livejournal.com/users/gravityboy/
Re: not production quality!
> And Debian... well, Debian... *sigh*
gcc-4.0 is the default compiler in unstable for just under a week.
Fedora Core
Fedora Core is suppose to be bleeding edge and it is Redhat's way of doing cheap QA for RHEL.
cheap QA
Not only for RedHat, but also for all GNU/Linux distributions :P Lots of new technologies (for example udev, hal, gcc 4, SELinux, Xen, gcj + native java stuff like Eclipse, GFS, OO.o2, X.org X11) get first incorporated into Fedora. After they are heavily tested, other distributions start using them.
lack of interest of the gcc,
lack of interest of the gcc, glibc and kernel developers to provide the community with a set of tarballs that actually compile against each other
glibc is a hog that needs slaughtering. I like uclibc. With gcc 3.4.4.
Production ready
Mac OS X 10.4 - Tiger, released April 29, 2005 is built with gcc 4.0, so I think if Apple says that is production ready ... it should be ...
"Now" as in "very very recently"
Saying in the same post "GCC 4.0 is ready and works now." and "GCC 4.0.0 has some pretty nasty bugs lurking in it." is a bit contradictory IMHO, especially only a few days after GCC 4.0.1 release..
So is GCC 4.0.1 able to compile KDE?
4.0.0 miscompiled KDE if memory serves.
Re: "Now" as in "very very recently"
Yes, GCC 4.0.1 can compile KDE. And MySQL and the Linux kernel, and a bunch of other packages. Just before the release of GCC 4.0.0 a patch was commited that broke the compiler. The sad thing was that the bug was discovered just a few hours after GCC 4.0.0 was released. GCC 4.0.1 doesn't have these problems. GCC 4.0.1 is also GCC 4.0 ;-)
Re: Good but...
According to GCC Bugzilla, GCC 4.0 branch has over 500 bugs that are open!
See this link.
Right, but 500 "pretty nasty bugs"? Hardly.
True, but a large number of them (the vast majority?) appear to be of the form "Waaa, my code got slower this release" or "The compiler takes longer/more memory than it should to compile this" or "The compiler gives me a spurious warning on this obscure corner case," which, while those are valid bugs, aren't "pretty nasty bugs." The ICE-on-valid and Incorrect-code-on-valid bug list is quite a bit shorter.
One thing I've learned and seen repeated again and again following compiler releases from multiple vendors is that performance does not and can not monotonically improve across all code from release to release, unless the changes to the compiler are trivial. Period. You will always have performance regressions on *some* piece of code. And when it comes to compiler warnings, I'd rather the compiler be slightly conservative and warn on something it can't sort out that looks questionable, rather than it be completely silent. Chances are, if it's warning on valid code, the code's still a bit questionable anyway.
Large number of Bugs making not suitable for production
Having over 500 bugs (notice GCC 3.4 has way less than this) for piece criticial of software is unacceptable for production system thus not many distribution shipping it at the moment.
Most software ships with known bugs.
Windows 2000 shipped with over 65,000 open bugs. I'd venture every "production worthy" software of any size shipped with open bugs.
Heck, look at the number of bugs open against the web browser you're currently using. It didn't send you running for NCSA Mosaic did it?
The *number* of open bugs isn't what matters, it's the severity. The 4.0 series will have plenty of performance regression bugs filed against it because it's changing its optimizer in fundamental ways.
Heck, there's a similar number of bugs still open against the 3.4 branch as there is against the 4.0 branch, so I don't know where you get by saying "GCC 3.4 has way less than this." Bugzilla, at this moment, shows 608 open bugs for 3.4.x.
Compiling yourself into oblivion? What?
Erm... unless you're recompiling glibc, I don't see how that can happen. And GCC's architected so that you can switch between multiple installed versions trivially, so that if you do hit a bug, you can switch to a different version w/out being terribly stuck. That's what the -V flag's all about.
I've got 3 versions of GCC installed on my Ubuntu box... 3.3.5, 3.4.4 and 4.0.1. The first two are in /usr/bin and the third is in /usr/local/bin. All quite happy, too, for the most part.
(Haven't succeeded in building a 32-bit app w/ the 4.0.1 compiler yet on my AMD-64 box, but I suspect the folks that put together Ubuntu for AMD-64 didn't really expect people would be compiling many apps for IA32 anyway. Compiling w/ 3.3.5 and 3.4.4 is challenge enough, getting all the libraries and such linked properly.)
about starting reading of GCC
hi.....i am new to gcc learning process.
as i see from your message that you knows great knowledge of gcc,please tell me...which file is starting of compiler c.
i have assigned to instrument gcc 4.0.0 for c language.but i don't know which file is related to jump action and starting.
thank you and please reply
jigar
GCCwiki
http://gcc.gnu.org/wiki
GCC 4.0.x vs 3.4, "compile into oblivion"
I'd like to start with the compile into oblivion. Anyone who has done serious system maintenance over a period of time ought to be aware of this. It does *NOT* include things like apt-get update or other commands that automate synching your system to the updates somebody else has done.
I've never run in to an official name for this phenomenon, so I'll call it what I've always called it: Propigating bugs. I'll start with my most recent one.
I had recently rebuilt a system to implement some major glibc upgrades. At the end of the process, the basic ftp program called "ftp" would segfault. Upon debugging it and grabbing a backtrace, I located the fault of the problem, or so I thought: libreadline. So I upgraded libreadline. No, the problem still existed.
Well, for that version of ld there was a bug floating around. I ran some tests, and the linker wasn't working right... for libreadline. So I patched ld, recompiled binutils, and then rebuilt libreadline.
Then perl segfaulted. and emacs. And joe. And every other program that had implemented a workaround some how or another for this particular bug. FTP worked perfectly.
Okay. So now I recompile everything that depends on libreadline, and voila. It works perfectly.
Now lets look at the simple version. FTP crashes because libreadline had a bug that only triggered for ftp, caused by a bad operation pulled by ld. Upon *fixing* that bug, I uncovered a *latent* bug in everything that had managed to get itself to work with a *bug* in libreadline. Now most of my system is unusable. Fortunately, the core apps I needed did *not* use libreadline, so I was able to compile my way out of what was almost a dead end.
Now. That gives the framework for how you can compile yourself into oblivion.
Now I'll mention one of the nastier bugs I've run in to when I have compiled a system into oblivion. I rebuilt the usual trio of suspects; binutils, gcc, and glibc. I wasn't ready to update the kernel includes yet, they were still pretty fresh. Everything's working, it's all passed a basic make check, shiney.
So I finish installing the glibc.
I have yet another thread bug. Alright. I recompile glibc. It passes make check. The system dies.
Further investigation reveals this: *SOMEHOW* signal passing had gotten fucked up. The checks were failing, but the error signal wasn't getting passed to the parent process; and since nothing or null equates with zero, everything was "passing".
But the system was fubar. That's what is meant by compiling into oblivion.
Now then, the ongoing gcc 4.x vs. 3.x debate: There's any number of hundereds of bugs that 99% of the people out there will never notice. You get a spurious warning, your resultant code size isn't as perfect as you like, your 2*(2+(8.6/2)) operation didn't get optimizied just the way you like it. Most of us are running 1GHz + machines and we can safely ignore these.
When I'm building a system that needs to be usable with 32Mhz and 70MB of RAM, *AND* load firefox without swapping, I pay attention to those bugs. A 2.4% performance increase isn't worth paying attention to if firefox loads in 2 seconds.
If firefox loads in a minute and a half, suddenly that's another two or three seconds you can shave off.
For the most part, tree-ssa holds the promise to be much more promissing then the RTL optimization. RTL has pretty much been refined to an artform, there's only so much that can be done with it as a structure and the GCC devs had come close to hitting it. tree-ssa holds the promise of being much more precise.