Slashdot Mirror


GCC 3.3 Update Status on NetBSD

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

3 of 33 comments (clear)

  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 Ded+Bob · · Score: 3, Interesting

    You may always try the TenDRA compiler.

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