Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC 3.2.1 Released

Posted by timothy on from the collection-that-keeps-collecting dept.

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

27 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 Wiz · · Score: 2, Insightful

      I wouldn't recompile a kernel unless I had to really, no matter what gcc does - that is assuming you are not having any strange problems. New bugs can creep into the gcc code as well, so you'd need to be careful. It is only since gcc 3.2 that some distros (RH & MDK & others?) have even started using the 3.x series for kernel compiles. The kernel can be very sensitive to compiler issues.

      As for MMX? Hmm, I'm not sure if I would. I'm not sure the kernel would benefit from any compiles like that anyway. Also, given MMX, SSE, etc have all seen compiler issues that have since been fixed in 3.2.1 it might be worth waiting a bit longer until we are sure the code for MMX is safe.

      Having said that, day to day (I run 3.2) here is what my default CFLAGS are set to for my Athlon:

      CFLAGS=-march=athlon-xp -mfpmath=sse -mmmx -msse -m3dnow

      I'd never use that lot to compile the kernel though, just whatever optimisations it turns on when you select your target processor.

    2. Re:Kernel? by mfos.org · · Score: 2

      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

    3. 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
    4. 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.

    5. Re:Kernel? by tzanger · · Score: 2, Informative

      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.

    6. 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. Old news by photon317 · · Score: 2


    I installed this on my Gentoo box two days ago, by typing "emerge -u gcc". Everyone else is hopelessly behind the curve :)

    --
    11*43+456^2
    1. Re:Old news by dimator · · Score: 2

      So are gentoo users the new version of debian users, with s/apt-get bla bla/emerge bla bla/ ?

      --
      python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
    2. Re:Old news by GreyWolf3000 · · Score: 2
      A few brave LFSers out there have been installing glibc 2.3.1 based-systems for over a month via gcc cvs (3.2 can't build 2.3.1).

      Everyone else is hopelessly behind the curve :)

      LFS is in the lead, Gentoo is in a distant second, and everyone else is, well, everyone else.

      --
      Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
    3. Re:Old news by photon317 · · Score: 2


      You've got it wrong, sorry :)

      My current gentoo box is running gcc 3.2.1 and glibc-2.3.1. Everything on my box was compiled with either gcc-3.2 or 3.2.1, including that glibc. I'm not sure exactly when glibc-2.3.1 went into Gentoo, but the current ebuild (-r2, probably the third version) is dated Nov 18th.

      --
      11*43+456^2
    4. Re:Old news by photon317 · · Score: 2


      I'm getting so fucking sick and tired of Anonymous Cowards. Every time one of them responds to me they're dead wrong and unaccountable for it.

      AC, whoever you are, I'll linux you under the table any day. I was rolling my own boxes without using a distro in 1994. I'm probably FAR more savvy than the average Gentoo-bashed like yourself. Gentoo gives me an excellent level of control for day-to-day use.

      If you need to build a 5 meg webserver, or a tiny busybox-based install, or whatever - go do what you need to do, manually, or using LFS, or whatever. But for my main desktop/development machine, Gentoo is my distribution of choice, it kicks all the other's ass handily.

      Yes, I take my box by its horns and teach it who's boss on a regular basis, with a soldering iron if need be. Why don't you post with some indentifying moniker and I'll come take your box by the horns too, you peice of shit AC whiner.

      --
      11*43+456^2
    5. Re:Old news by (startx) · · Score: 2

      both glibc 2.3.1 and gcc 3.2.1 are in slackware-current, and have been for a while (few days at least). Everyone talks about the slow releases of slackware, but damn if -current isn't bleeding edge & stable at the same time.

    6. Re:Old news by photon317 · · Score: 2


      Does that include yours?

      --
      11*43+456^2
    7. Re:Old news by Ed+Avis · · Score: 2

      When you upgrade gcc on your Gentoo box, does it recompile everything with the new gcc?

      --
      -- Ed Avis ed@membled.com
  5. How about the Intel Compiler? by IrvineHosting · · Score: 2, Interesting

    From all I've read and the benchmarks I've looked at, ICC (Intel Compiler) is 99% compatible with GCC and code generated is 30%-50% faster.

    This difference may be enough to push Linux way past Microsoft if Linux apps run that much faster than Microsoft apps.

    It seems like its crazy that the distros (REDHAT, SUSE, etc) don't use ICC as a drop in replacement for 386+ compiling.

    For other platforms use GCC, but why should 90% of users be punished for the sake of cross-platform features (sounds like java)?

    When will the linux kernel be compatible with ICC and why aren't more using it??

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

    2. Re:How about the Intel Compiler? by duffbeer703 · · Score: 2

      Q: "Why doesn't Intel dedicate engineers to optimizing gcc's code generation for ia32 and ia64?"

      A: Intel is not a charity. Software Engineers do not optimize compilers for free. Giving away the work of well-paid engineers is not a very intelligent business decision.

      --
      Conformity is the jailer of freedom and enemy of growth. -JFK
    3. Re:How about the Intel Compiler? by dvdeug · · Score: 2

      Software Engineers do not optimize compilers for free. Giving away the work of well-paid engineers is not a very intelligent business decision.

      Then why does Apple work on optimizing gcc? Because giving away the work of well-paid engineers can be a very intelligent business decision. The deeper response is that ia32 dominates the field, and it's hard to optimize for Intel chips and not AMD, and that Intel makes enough money from its compiler that it offsets the need to have the best compilers for their chips.

    4. Re:How about the Intel Compiler? by duffbeer703 · · Score: 2

      You circled around the answer alot.

      Apple does not sell a C compiler. Intel does. Intel's bread and butter is ia32 chips running Microsoft OS's -- contributing to project that would improve a free replacement to Microsoft's OS would be rather dumb.

      Would it make sense for Toyota to provide engineering support to Fiat for free?

      --
      Conformity is the jailer of freedom and enemy of growth. -JFK
    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
    7. Re:How about the Intel Compiler? by cimetmc · · Score: 2, Interesting

      I think it's mainly a support issue. The money Intel gets from the compiler is probably used to pay the people that have to support the compiler. Software companies would certainly want to get professional support, and the cost of the compiler is certainly not an issue for them. For those people who pay for the Intel compiler, Intel gives support. If Intel gave away the compiler to everyone, they could not give the same level of support to everyone, and professional users might not be keen to use the compiler without proper support behind it.

      Marcel

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

      This is the old argument that RMS addressed in the GNU manifesto. If companies want support for the compiler, and are willing to pay for compiler plus support, surely they would be willing to buy support and get the compiler as free software.

      No, it must be the case that there isn't enough demand for support to make it economical to make the compiler free and sell support. Intel has to make the compiler itself payware in order to get the most money from it.

      --
      -- Ed Avis ed@membled.com
  6. System include path by silvaran · · Score: 2

    One of the biggest fixed I've noticed is that warning about the system include path. When you specify something like -I/usr/include (redundant, which often happens when you configure with your prefix as /usr instead of /usr/local), you'll get warnings about the system include path search order being changed. Sometimes it's treated as an error, other times just a warning, but I've had 20-30 packages fail to compile because of this, and it's a bitch to get rid of when you have to sift through about 10-20 makefiles. I upgraded to 3.2.1 and haven't looked back.