GCC 3.2.1 Released
Szplug writes "GCC 3.2.1 has been released; many C++ bugs, & notably for x86 users, MMX code generation has been fixed. From the notice,
".. the number
of bug fixes is quite large, so it is strongly recommended that users of
earlier GCC 3.x releases upgrade to GCC 3.2.1."
Here are overview and detailed change notices. Download here [gnu mirror site]."
Here are overview and detailed change notices. Download here [gnu mirror site]."
".. the number of bug fixes is quite large, so it is strongly recommended that users of earlier GCC 3.x releases upgrade to GCC 3.2.1." ...and if you're still using 2.95.3 for real work, continue to do so.
Would it be a viable consideration to recompile our kernels in light of this better MMX code generation? Better yet, is it generally a good idea to recompile our kernels whenever a bugfix release of GCC comes out?
-- I was raised on the command line, bitch
Apple has been shipping 3.1 in the 10.2 development tools. Last time I checked Apple applied its own patches to gcc also, in the version it ships.
It seems to be
why aren't more using it??
It's proprietary software. A better question is "Why doesn't Intel dedicate engineers to optimizing gcc's code generation for ia32 and ia64?". This would be a much more useful contribution.
~Phillip
I think one of the main reasons why Intel does not contribute to GCC is not that they want to make money selling their compiler, but rather that they are not satisfied with the results of prior contributions they did to GCC. I might be wrong, but I think Intel contributed to GCC at least twice in the past. When the Pentium processor was released, Intel was quite dissatisfied by by the performance of the GCC code on Pentium processors, and so they took the GCC source code and made a number of improvements to it to generate much better Pentium code. They than gave back the modifed source code as some igcc compiler or so. This modified GCC compiler was then used as a bases of the PGCC compiler, but they were never really picked up by the GCC project until EGCS became GCC. Later on, I think Intel sponsored the GCC project to pay a developer to improve Pentium II support, but once again, it took I think something like 2 years until the contributed effort was mirrored in a released GCC version. So I think that in the end, Intel decided that it was not effficient to contribute to the GCC project as the contributions took too long to show an efffect on actual GCC compilers and this would make newer Intel processors run inefficiently for too long a time on GCC based systems. With their own compilers, Intel themselves are master of the release process, and they can make sure that they have a new compiler at the same time they officially start shipping a new processor generation. Finally, there is another big hurdle Intel may face. Especially processors like the Itanium and the P4 take a lot of modifications to the compiler to make efficient code. However because GCC has to support a wide range of processors, big architecture changes aren't easy to implement at the risk of breaking compatibility with other processors supported by GCC. So overall, I think Intel chose to make their own compilers because to them, that is the most efficient approach that guarantees them to have good compilers for new processors in an acceptable time frame. Marcel
Then you have to ask, if Intel has its own compiler, why do they not release it as free software? They must think that the money they make from compiler sales outweighs the increased sales of Intel processors from having a good free compiler for them. I can imagine this is true for IA-32 since code optimized for a P4 also runs well on an Athlon, so Intel wouldn't particularly be promoting their own chips (except for those choosing between say SPARC and i386 for their new supercomputer, and there aren't many of those).
-- Ed Avis ed@membled.com