Slashdot Mirror
GCC 3.2 Released
bkor forwards the GCC 3.2 release announcement, without attributing it as such: "The GCC 3.2 release is now available, or making its way to,
the GNU FTP sites. The purpose of this release is to provide a stable platform for OS distributors to use building their next OS releases. A
primary objective was to stabilize the C++ ABI; we believe that the interface to the compiler and the C++ standard library are now stable. There are almost no other bug-fixes or improvements in this
compiler, relative to GCC 3.1.1. Be aware that C++ code compiled by GCC 3.2 will not interoperate with code compiled by GCC 3.1.1. More detail about the release is available. Many people contributed to this release -- too many to name here!"
Be aware that C++ code compiled by GCC 3.2 will not interoperate with code compiled by GCC 3.1.1.
When will they understand that breaking interoperability is not the way to go forward? The reason MS Windows is where it is now is that you don't have to replace/recompile all your software every few months.
This is front-page material because GCC is one of the most important building blocks of the free/open-source software world.
GCC is the de facto compiler for GNU/Linux and *BSD systems. Furthermore, the Linux kernel currently hasn't been ported off GCC. Without GCC, free *NIX systems would have nowhere near the importance they have now.
#define sig "Every social system runs on the people's belief in it."
Have you even entertained the notion that the Quake engine has a real bug?
Hopefully they will freeze the C++ interface for a long time and linux/bsd distributions will not have backward compatibility issues when upgrading GCC. THANK YOU SO MUCH to al the GCC developers/contributors.
Agreed. I have noticed far fewer postings on here announcing the latest developments in free software. I was afraid slashdot was going mainstream and donned the corporate hat or something, passing up news of community acheivements.
Seeing news like this to be discussed and picked apart in a large forum is always a good idea in my opinion. GCC is important for the way my gentoo linux box operates, so yes, I'm VERY interested in these articles. This is news that lets me be aware of issues I may encounter in the future.
It seems to me people complained when an article was posted about Yet Another Kernel Release. I can understand those people weren't interested and may have had better sources elsewhere, but I found slashdot a great place to discuss these issues since the beginning.
No. Your whole system will have crapped out after 3 minutes with a compile error, just waiting for you to come back on Monday.
The masses are the crack whores of religion.
Please remember that the C++ standards comitee encouraged vendors to use different (incompatible) ABIs for C++. C++ compilers were not supposed to interoperate, because they thought that this would never work, because the compiler had to do far too much things outside the object files (compilation units) for exception handling and initialization code.
And, for all compilers I know, they were right.
You really cannot blame the GCC people for this. Whenever they have to change the internal handling of exceptions, templates and stuff internally, it really is the best choice to change the ABI.
The C++ standard was never designed to make code compiled by different compilers link. And gcc2, gcc3.1, and gcc3.2 are different compilers because the internal handling of these very complex structures changed.
42. Easy. What is 32 + 8 + 2?
You know that GCC has been tested more with optimization turned on than with -O0 (no optimization)?
About two years ago, I was compiling linuxconf. The Makefiles forced -O0 (no optimization), and its author, asked, said that "there will be errors by the compiler when I turn on optimization, so I force it to be off for everyone."
It turned out there was a bug in his code. It wasn't gcc's fault. It just showed up when you used optimization. But, btw, the code of Linuxconf has been ugly as hell since I first saw it.
Code that won't compile (or break) at -O1 is crap.
42. Easy. What is 32 + 8 + 2?
"Why don't opensource project communicate things like this to distributions."
They DO, if you only *listen*. This subject is extensively discussed on the gcc mailinglist, discussed by gcc developers and people from distributions. Of course, their decision is still *their* decision, but they knew gcc 3.2 would be around there really soon.
I do all my work in Linux. I've seen some audio tools, and the more recent stuff is starting to look "professional". But I'm a CLI guy myself.
:)
I have two types of tools that I have written. When I first started messing with audio creation, I followed the usual Unix tool route. Read from the standard in write to the standard out. I wrote filters to do things like:
cat 16-bit-unsigned.raw | noise-gate 1024 > 16-bit-unsigned.raw~
To set all samples below 1024 to 0.
I basicly scoured the web for C implimentations of various digital filters and effects. Once I got the idea of what was going on I started to write my own.
I also have written tone generators for all the basic wave forms.
What I'm working with most now, is a program I call an audio render. I had used POV-Ray since the 0.5 release, and loved the scene description language (very C like). I thought it would lend itself well to generating a stream of samples rather than pixels. So far the results are very interesting. I'd like to release it at some point, but I used most of POV-Ray's parser, and some other bits of code. It is most definatly a derived work, even if it does something totally different. Unfortunitly POV-Ray's license is kinda restrictive in this respect. Besides it isn't ready for primetime yet, and the POV Team are talking about relicensing at GPL, so maybe I'll get it to a point where I think others could use it about the time POV gets GPLed.
Wow, I wrote a lot. Please go gentle on the moderation.
If you have no insight whatsoever into the internals of a system -- such as is the case when viewing the inner workings of the universe from a pre-Einstein perspective -- then Occam's Razor can indeed prove useful.
But when you are told by people who understand what's going on inside what are the implications of failures appearing when compiling with certain optimizations enabled, then Occam's Razor no longer applies in the way that you think.
In fact, it applies in the exact opposite way, to wit:
A compiler represents, compared to the vast amount of code it compiles, maybe .01% of the total code involved (compiler plus code compiled by that compiler).
(The GCC compiler probably represents much less than that.)
Testing the compiler includes making sure it "correctly" compiles a substantial portion of the target software.
If the compiler offers an optimization that end users can turn on, one which is carefully documented and at least moderately well-tested, but that is known to expose bugs in the code it is compiling, yet has not been found to itself have a bug when enabled while compiling a substantial portion of the code...
Otherwise, one would presume a much larger body of software would fail in ways that are easy to track down to a compiler bug (especially in GCC's case, where the compilation phases are so transparent via RTL dumps and the like) when that optimization was enabled.
Especially in this case, where the kind of application bug is of a type that was widely deployed due to a combination of factors, even though I know the internals of GCC argue pretty strongly for the ability of a bug in the optimization being discussed to hide most of the time and still bite a few applications, I'd tend to lean, based on what you've said, towards a 75-25% likelihood of application bug versus GCC bug in this particular case.
In short: general rules are very useful, but they cease to apply to the extent specific information is available.
Practice random senselessness and act kind of beautiful.
I got into a good habit at my first SysAdminning job that prevents this kinda problem. Make a directory in /usr/local/package/. Make a subdirectory dist, and untar the source there. configure --prefix=/usr/local/package/. make and make install, and then when you have all your /usr/local/package/bin/ and lib directories, make sym links.
/usr/local/* | grep '-> /usr/local/package/'`; do rm $F; done".
/usr/local/package/version/architecture/, but I consider that overkill on my home machine.
"Uninstalling" and "upgrading" becomes as easy as "for F in `ls -l
At the aforementioned job, the directory I installed to was actually
On some areas, GCC is faster, while on other areas, GCC is slower than Intel C++. But all in all, GCC is quite good.
I'd like to see a real benchmark of this. The same exact thing is said about every language/compiler by its proponents (think java vs c/c++, etc)...
That's just like the "viewer response" I saw CNN airing sometime around 2001-09-13:
It's a nonsensical question, although you can take personal action to resolve your concerns, if you choose. (You can simply decide to feel safe, or to never feel safe again; you can decide to undertake the kind of in-depth study of C++ ABI issues and GCC's code base to determine whether it's stable, or to accept that it'll never be stable. These are all coping mechanisms. Nobody else can answer the questions for you.)
In the meantime, if you want to "stick with 3.1's slightly-broken ABI", then what's preventing you from doing that?
Practice random senselessness and act kind of beautiful.
GCC 3.2 is just a bug fix release to 3.1. It does not add any new features or optimizations. It's actually just the 3.1.1 code plus the ABI fixes. The new version number has been chosen because of the ABI incompatibilties.
As for deciding whether to use 3.2 or not, it may depend on what you have been using before.
If you have GCC 3.1x and you have C++ libraries, you may stick with GCC 3.1.1 until GCC 3.3 is there. This will postpone any incompatibility mess until you get something in return for it.
You you are using a pre 3.1 GCC version and you want to upgrade, you should absolutely skip 3.1.x and go to 3.2 right away.