Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC 3.3 Update Status on NetBSD

Posted by michael on from the minor-issues dept.

Dan writes "Matthew Green says that the gcc3 update on NetBSD is going well. They are almost ready to switch several platforms including i386, sparc, sparc64, arm, mipsel, alpha. Mipseb and m68k are almost done. Sets lists need to be updated and building more kernels with gcc3.3 are the things still pending."

12 of 33 comments (clear)

  1. Waiting for 3.4 by Markus+Registrada · · Score: 4, Informative
    I hope they are not planning to stick with 3.3 for the indefinite future. Gcc-3.4 is where the major improvements are going, and its ABI is meant to be stable for a long time. The 3.3 series is just for practice, as it were. For example, getting iostreams to take advantage of NetBSD's UVM, and expose zero-copy I/O at the user level, will happen early in the 3.4 series. 3.4 is getting precompiled headers and other practical work on faster compilation.

    The same advice goes for Debian and the other distributions as well (although of course Linux doesn't have UVM yet). It would be a serious mistake to put in that much work just for 3.3 itself, although the work isn't wasted because after getting everything working on 3.3, switching to 3.4 should be (technically) pretty easy.

    1. Re:Waiting for 3.4 by ctr2sprt · · Score: 4, Interesting
      I'm not worried about the ABI compatibility, I'm worried about the reliability of the compiler. gcc has been an extremely dangerous product for some time now. If you run anything more than -O you're in real danger of getting broken code, even on popular architectures and operating systems.

      If I were running things over at NetBSD HQ, I'd be much more worried about that than feature-completeness.

    2. Re:Waiting for 3.4 by mirabilos · · Score: 1

      Don't they say that (stable A[BP]I) every time? :)

      Okay, enough the flamebait. I've tried to update
      MirBSD (which went from ports-gcc-3.2.2 to in-tree
      backup gcc-2.95 due to a failure in the gcc 3.3
      update for the ports) to an in-tree 3.3 gcc, and
      somehow it failed.

      Right now I've imported gcc 3.3.1, but have no
      idea whatsoever if it'll work.
      If someone wants to help, reply (I get mailed).

      --
      My Karma isn't excellent, damn it! (And /. still does not get UTF-8 right in 2012. Wow.)
    3. Re:Waiting for 3.4 by Ded+Bob · · Score: 3, Interesting

      You may always try the TenDRA compiler.

    4. Re:Waiting for 3.4 by badvictor · · Score: 1

      You got anything to back that up? Dangerous compared to what? THE most dangerous compiler out there is MS Visual C++. It does not comply with standards and often produces broken code. gcc on the other hand has a very good track record of keeping up with standards, and producing very robust code even with the highest level optimization.

    5. Re:Waiting for 3.4 by Anonymous Coward · · Score: 1, Insightful

      "(although of course Linux doesn't have UVM yet)"

      What an utterly meaningless statement. UVM was a redesign of the Mach-derivied 4.4BSD VM (which was in turn a replacement for the original, highly VAX specific VM).

      Linux's VM is a totally seperate implementation from either the old Mach-based VM, or UVM.

      You might as well say "of course, NetBSD doesn't have NET4 yet"; of course it doesn't, it has it's own, seperate TCP/IP stack.

      It's because of people like you that I have to preface "I use NetBSD" with: "I'm not a crazed, uniformed zealot, but ". You're giving the Linux crazies a real run for their money.

    6. Re:Waiting for 3.4 by Markus+Registrada · · Score: 2, Interesting
      I'm afraid I'm one of the Linux crazies.

      Furthermore, I think NetBSD's (and OpenBSD's) UVM zero-copy features are positively uttergloss. I wish Linux was poised to offer anything even close. There's no way, though, that Linux will have them before 2.8 or 3.0, in two to five years.

      Making libstdc++ able to use those features transparently, once they do appear, should hasten their arrival. There's nothing like the prospect of making dozens (or hundreds) of existing programs several times faster on millions of machines to inspire kernel improvements. Having them already demonstrably running faster on a competing OS helps too.

      First, of course, we have to get those dozens (or hundreds) of kernel-optimization-ready programs deployed, which means making the improvements and getting a release that has them out into the world. Fortunately the improvements are an optimization even without UVM or its imagined Linux equivalent, because they will speed up disk file I/O operations too.

    7. Re:Waiting for 3.4 by vesamies · · Score: 1

      I'm quite happy with the new GCC. It's a big improvement over the old 2.95 version. Btw, it's easy to build a system with the new GCC, running fine here, although my kernel is still built with 2.95.

  2. NetBSD by kernelistic · · Score: 3, Insightful

    It's nice to see NetBSD updating their compiler suite to something newer. Compiling and testing for so many archs and procs is quite an undertaking!

  3. Re:Developer laments: What Killed FreeBSD by beefdart · · Score: 1

    Holy CRAP! I have never seen this before!!

    I guess its time to go to work and quickly migrate our 350 production FreeBSD machines to something not dead...

    Thank you so much for telling me, all this time I thought I was using the fastest, most stable OS for x86, but it turns out a fat-gay penguin must have stomped on my OS.

    Choke on it and die you Linux-Halfwit.

  4. Re:*BSD is dying by beefdart · · Score: 1

    Holy CRAP! I have never seen this before!! I guess its time to go to work and quickly migrate our 350 production FreeBSD machines to something not dead... Thank you so much for telling me, all this time I thought I was using the fastest, most stable OS for x86, but it turns out a fat-gay penguin must have stomped on my OS. Choke on it and die you Linux-Halfwit.

  5. Re:Developer laments: What Killed FreeBSD by Phactorial · · Score: 1

    s/fastest//