login
Search
Mark Mitchell announced the availability of GCC 4.0.2. He explains, "this release is a minor release, containing primarily fixes for regressions in GCC 4.0.1 relative to previous releases." GCC 4.0.1 was release two and a half months ago on July 7th [story]. A list of bug fixes in 4.0.2 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.2 from a gcc.gnu.org mirror.
From: Mark Mitchell [email blocked] To: gcc mailing list [email blocked], gcc-announce [email blocked] Subject: GCC 4.0.2 Released Date: Wed, 28 Sep 2005 21:05:04 -0700 GCC 4.0.2 has been released. This release is a minor release, containing primarily fixes for regressions in GCC 4.0.1 releative to previous releases. http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2 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.2 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
Novelty
While this is a real release, because it is a slower compiler, and makes bigger output files that also run slower then previous versions of the compiler, it's really a technology test release then something people should actually use :) Now when 4.1 and later come out I'll be taking a real close look.
4.0.x isn't always slower
Yes, 4.0.x has had mixed results. It's not always faster, since the optimizer infrastructure switched to the new SSA form. Not all of the optimizations were available or turned on in 4.0.x that were in previous versions.
But, in some cases, 4.0.x is noticeably faster than 3.4.x. Also, the bugs will never get fleshed out of 4.x if people don't use it. So, I say, install it and use it as your default compiler, but keep 3.4.x around for if/when something breaks in 4.0.x. Oh, and if does break, file that bug report!
Incidentally, the above advice is intended for more casual users, or people who don't mind bleeding edge. If you're trying to build Apache to run your eCommerce site, I betcha you're building with something more like 2.95.x anyway...
Yes, but is the ABI stable en
Yes, but is the ABI stable enough to support keeping two compilers in slots?
Or is the compiled-by-two-versions system going to be a Windows-3.0-style stability nightmare?
Yes, but is the ABI stable en
Yes.
Shure
Shure it is :)
GCC projects
There seem to be masses of GCC projects out there - some (like OpenMP support) are offered as branches off the GCC CVS tree, though it's not clear to me how synchronised the branches are. Others (like frontends for D and PL/I) are patches which may or may not work on snapshots other than the ones they are for.
There are even quite extensive projects and patchsets for building cross-compilers, which can be hard to find unless you know what to look for. I'm also not convinced the building of cross-compilers should be as difficult as it is - there have got to be better arrangements!
GCC is great, don't get me wrong, but there must be better ways to handle abnormal cases.
Re: GCC projects
Building a cross-tool just happens to be hard. Tough luck. Use crosstool. And read the information about building cross-compilers on the GCC wiki (http://gcc.gnu.org/wiki/).
OpenMP is on a branch that will be merged for GCC 4.2.
Fortunately GCC developers have long ago stopped caring about what kernel hackers think of GCC -- all they do is whine anyway.
Not listening, or not automatically complying?
There's a big difference between not simply automatically following someone's ideas (which is a Bad Thing) and listening to others but regarding their comments critically (which is a Good Thing). It's also important to distinguish someone saying "isn't there a better way?" from those who say "damnit, it should be done my way!" The former group are (usually) willing to listen to those who say "no, there really isn't", but aren't willing to take it for granted just because nobody has done things differently.
Personally, I don't know of many kernel hackers who use PL/I. Well, unless they're adding a Multics compatibility layer. (Hmmm...) Crosstools is broken for certain platforms, though the developer seems to be keen on fixing it whenever he has information on what to fix. I've found that it's better to use the Linux From Scratch guides, if they exist for a given platform, though.
I wouldn't have thought cross-compilers need be difficult - surely you'd just want an absolute minimal bootstrap C library in a pseudo-assembly format. All it needs are the functions GCC and GLIBC need in order to build correctly and cleanly - which should really be just the crt?.o files and ONLY those aspects of threading that are actually required for those two packages. And anything that is required to be there, but isn't actually going to be used in building the toolchain, can simply be a stub. This means that actual coding could be pretty minimal.
Should this be done? Got me. It isn't done, so I guess there's a reason (beyond there being extra work, and not a vast interest in cross-compiling) but I couldn't tell you what that reason was. It would be good to know from a GCCer as to what that reason was, or even that the GCC developers have actually GOT a reason, even if we never do find out what it is.
OpenMP is on a branch that will be merged when it's good and ready. I hope, anyway. It's folly to say it'll be in such-and-such a version, when you have absolutely zero idea when 4.2 is actually going to come out, when OpenMP will be stable enough to be in the main branch, or what demands will be placed on the GCC developers between now and then. Unless you're psychic, you have no possible way of knowing what problems the OpenMP developers will run into - or, indeed, what problems other coders will run into. For that matter, you can't even tell what strokes of brilliance they may have. An OpenMP developer may wake up tomorrow with a fix that'll make OpenMP frontend-agnostic, totally stable and bug-free. The only certainty about any forecast is that it's certainly going to be wrong in some respect.
Regardless, it doesn't resolve the problem that components are bloody hard to merge. Far harder than logically makes sense, although it may well be that on close-enough inspection it DOES make some sense. What it requires is for someone to point out WHY it makes sense, rather than whining about whining, when there's no whine to whine about. If you want whine that badly, there's probably a liquor store nearby.
Is ARM branch in GCC 4.0.2 release?
Just want to make it sure.