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]."

9 of 56 comments (clear)

  1. But is it stable? by Anonymous Coward · · Score: 5, Insightful

    ".. 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.

  2. Kernel? by fulldecent · · Score: 3, Interesting

    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

    1. Re:Kernel? by jericho4.0 · · Score: 3, Informative
      I don't think you would realize any real gains by recompiling your kernel. Recompiling your video/graphics/sound stuff, maybe. Recompiling might fix a bug or two, but if your system is stable thats no excuse for a recompile.

      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
    2. Re:Kernel? by rplacd · · Score: 3, Informative

      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.

    3. Re:Kernel? by dvdeug · · Score: 3, Informative

      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.

  3. Unless your a Mac OS X user by AIXadmin · · Score: 4, Informative

    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.

  4. Re:How about the Intel Compiler? by diaphanous · · Score: 3, Insightful
    When will the linux kernel be compatible with ICC

    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

  5. Re:How about the Intel Compiler? by cimetmc · · Score: 4, Informative

    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

  6. Re:How about the Intel Compiler? by Ed+Avis · · Score: 3, Interesting

    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