Slashdot Mirror
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]."
Of course, you don't need an excuse to make a new kernel. Go nuts. If you pull another 20fps out of UT2003, please tell us about it.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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.
Kernels are a good test for gcc. Often gcc's optimization or instruction scheduling code has led to unusual system behavior. Sometimes your system'll panic, sometimes things will seem flakey, especially with device i/o (think inline assembly code).
For what it's worth, I've been using FreeBSD 5.0-CURRENT with gcc 3.[12].x for months now. I've compiled my entire system with -march=athlon. To be fair, it's just my desktop -- not a server.
Non-commercial only. So no good for Redhat, but everyone else is welcome to use it.
I'm running 2.4.19 compiled with gcc 3.1 and I haven't had a problem. What I do have is a 42 day uptime
Same kernel, same compiler (maybe a 3.1-pre though): 85 day uptime. And my notebook's been running 2.4.19 and 2.4.20-pre definately compiled with 3.0.4 with no troubles.
I am pretty sure that all the bad things related to gcc3 were in C++, not C.
Kernels are a good test for gcc
I don't know about FreeBSD, but the history of Linux (the kernel) and GCC has too many incidents of a GCC upgrade breaking the kernel, and the GCC hackers and the kernel hackers having a nice flame war over who's at fault. I'd rather let one of them test it out, rather than become a roasted guinea pig.
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