OpenBSD Journal

OpenBSD/i386 switches to gcc3

Contributed by phessler on from the flag-day dept.

Peter Valchev writes: For everyone following -current, notice i386 switched to gcc3 today. The upgrade-minifaq has been updated with instructions:

http://openbsd.org/faq/upgrade-minifaq.html#3.6.5

WARNING, this is a FLAG DAY, so you have to either exert special care and do things by hand as above, or wait for snapshots to appear. Specifically, it will be best in your favour to rebuild/reinstall all your packages from scratch as well.

(Comments are closed)

Comments

  1. By phessler (64.173.147.27) on

    Note that updated snapshots are scheduled to appear in 24 hours. Fighting with a gcc2->gcc3 migration is horrible, please just use snaps.

    Comments

    1. By Anthony (68.145.111.152) on

      I know they had very serious reservations about 3.3 (along with Linus), so why did they switch? The way I see it, there's two possible reasons:

      1. 3.x is now good enough that the upgrade is worth it.
      2. Maintaining 2.9 has become too much of a PITA for it to be worth it.

      Comments

      1. By tedu (67.124.88.142) on

        3.3.5 fixed many bugs, there's been more time for review, testing, ...

        Comments

        1. By SH (82.182.103.172) on

          On the misc mailing list one of the complaints against gcc 3 are the longer compile times (about 40% ?). This has not changed?

          SH

          Comments

          1. By Brad (204.101.180.70) brad at comstyle dot com on

            No, this has not changed.

    2. By Anthony (68.145.111.152) on

      I know they had very serious reservations about 3.3 (along with Linus), so why did they switch? The way I see it, there's two possible reasons:

      1. 3.x is now good enough that the upgrade is worth it.
      2. Maintaining 2.9 has become too much of a PITA for it to be worth it.

  2. By antonios anastasiadis (193.58.186.135) on

    well,let me be the first who says... yipeee!

    Comments

    1. By Lennart Fridén (213.64.159.28) on

      I'm glad to hear that the OBSD project finally adds gcc3! It's going to be good to have the same compiler suite across all my platforms.

      Comments

      1. By tedu (64.173.147.27) on

        that of course depends on what "all my platforms" means.

        Comments

        1. By Lennart Fridén (213.64.159.28) on

          No, not quite. The subjective "great" I'm feeling doesn't really diminish with the a lower number of platforms. AFAIK, the OpenBSD project has been one of the slowest to adopt gcc3 as its default compiler (for good or for worse). Now, I'm merely stating that its going to be nice not to have to deal with two deifferent major versions of gcc no matter what platfrom I'm working with. For now, its Windows/Cygwin, OpenBSD/i386, and the odd Linux/i386. Hopefully MacOS X will show up in that list as well as a few other OSes and CPU archs.

          Comments

          1. By Marc Espie (62.212.102.210) on

            The only real good point about gcc3 is the C++ support.
            It's very close to the actual standard, where gcc 2.95.3 was
            really poor in that regard.

            That said, the compilation speed is abysmal, the resulting code is nothing to write home about.

            What matters for us is:
            - support for all kinds of new platforms, like sparc64, amd64 which are really not supported by gcc 2.95.
            - better diagnostics. The error messages are better. The builtins work like they're supposed to (for instance, you now get a warning that exit() is not defined if you forget to #include <stdlib.h>. gcc 2.95
            was completely bogus there).
            - almost supported by the FSF. Not really. If it's not the greatest and latest, it's not supported.

            BTW, the latest stable branch of gcc at the FSF is 3.4. We won't switch to that, because it's even slower, the C++ parser rewrite means that C++ takes an insane amount of memory to compile, and there are even more issues to fix in third party code.

            Maybe, just maybe, gcc 4.1 will be good and provide better code, and not yield huge amounts of compile time and consumed memory.

            I don't have that much hope for it.

            For a portable compiler, GCC more and more is a *386-only* development platform: it's so slow and uses so much memory as basically being totally unusable on anything but a fast i386 or amd64 with lots of memory.

      2. By RC (4.8.17.8) on

        > I'm glad to hear that the OBSD project finally adds gcc3

        It hasn't been added, really... It's been available for quite some time. It's just becomming the default, and put into the base system now.

        Comments

        1. By Lennart Fridén (213.64.159.28) on

          Okay, poor phrasing on my part. Still, I'd say that most people use the compiler that's provided with the system so for them the difference between having gcc3 added and gcc3 set as the default is fairly huge.

          Comments

          1. By Brad (216.138.200.42) brad at comstyle dot com on

            Ya, if you like everything compiling that much slower..

            Comments

            1. By Lennart Fridén (213.64.159.28) on

              Compile time isn't everything. You run programs more often than you compile them.

              Unless of course you got a compile farm at home/work...

              Comments

              1. By Brad (204.101.180.70) brad at comstyle dot com on

                And guess what? If you're worrying about run-time performance then GCC is about the worst compiler to use.

                Comments

                1. By Lennart Fridén (213.64.159.28) on

                  Got a better alternative to using GCC for OpenBSD? Last time I checked, the Intel compiler wasn't available for OpenBSD and there's this little thing called "license issues".

                  That said, I don't think OpenBSD is going to spin off an OpenGCC project anytime soon (or ever) so we're stuck with GCC.

  3. By Anonymous Coward (220.240.54.229) on

    So How much slower and Fatter is i386 now?

    Comments

    1. By Anonymous Coward (24.65.228.16) on

      What? You're not going to jump perverbial band wagon and go for all of those crazy compile flags? Tsk-tsk-tsk.

      Comments

      1. By Anonymous Coward (68.78.135.106) on

        --omg-optimize

    2. By RC (4.8.17.8) on

      > So How much slower and Fatter is i386 now?

      It should become FASTER as a matter of fact, it's only the compiling that becomes slower.

      The optimization flags available should make things rather fast, if they work, that is. In my experience with gcc2.95 on OpenBSD, anything but the most basic flags often result in corrupt binary junk. The other BSDs have the same problems, but to a lesser extent than I've seen with Open.

      Comments

      1. By Anonymous Coward (69.197.92.181) on

        No, the other BSDs, and linux have the same problem, to the same extent. Compiler bugs don't actually care what kernel you are using, they exist regardless.

        Comments

        1. By RC (4.8.17.8) on

          > No, the other BSDs, and linux have the same problem,
          > to the same extent.

          Complete bull. I'm sure I could find dozens of test-cases where compliling several different programs with certain flags works on Linux or FreeBSD, but not on OpenBSD. Or, programs that compile correctly on Linux with certain opts, but not on any of the BSDs with the same opts.

          Your baseless assertion that I'm wrong does not prove anything, except that you should not be trusted.

          Comments

          1. By Marc Espie (62.212.102.210) on

            We have an old saying that says: put up or shut up.

            Get those testcases out, so that we get a chance at fixing them.

            Saying that stuff doesn't work is useless.

            If you're half as competent as you say you are, you'll be able to write down testcases in no time, and you'll be able to give them to us.

          2. By Anonymous Coward (69.197.92.181) on

            And your baseless assertion that you're right doesn't mean anything either. Seriously, the same version of gcc will produce the same broken code wherever you compile it. OpenBSD hasn't customized gcc so much as to break optimizing, linux users just think random crashes and failures are normal, so optimizing bugs aren't considered on linux.

            If you really have such strong proof that its openbsd specific, then perhaps you should stfu and post a couple testcases for everyone to try.

          3. By djm@ (218.214.226.34) on

            Therefore your own baseless assertion proves that you can't be trusted either. "I'm sure I could find dozens of test-cases..." is not evidence unless you actually show some test cases.

      2. By Brad (216.138.200.42) brad at comstyle dot com on

        You're being very optimistic expecting any speed increase, in reality you will NOT see any increase.

    3. By Anonymous Coward (68.100.75.121) on

      My experience indicated about a 50% longer make build of -current on i386. This was on a rather slow PII. From about 5 hours to 7.5.

  4. By Anonymous Coward (198.175.14.194) on

    Hopefully, with 3.3.5, i386 binaries are quicker, not slower, except gcc itself :)

  5. By mirabile (81.173.168.114) on http://mirbsd.de/

    For all the optimising fans: www.funroll-loops.org ;)

    Funny that OpenBSD defaults, system-wide, to
    -fno-zero-initialized-in-bss whereas this has
    not bitten me today _at all_ (I compared a
    kernel built with the older gcc 3.2.3 and one
    with the brand-new just ported gcc 3.4.4 and
    found that exactly zero variables have moved
    from .data to .bss (if eg. uextraloc were
    static, it would have)...).

    And I was surprised of how good quality gcc 3.4
    is, compared to gcc 3.2 (but it is even slower,
    admittedly, and produces larger code).

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]