OpenBSD Journal

gcc 3.3.2 imported into CURRENT

Contributed by jose on from the new-compilers dept.

SH writes: "OpenBSD is updating the compiler, as can been seen from CVS :
CVS archive

It was my impression that the OpenBSD developers was none to happy with newer gcc than 2.95 due to slow compile times."

This may make upgrading interesting ...

(Comments are closed)

  1. By Anonymous Coward () on

    Could someone maybe summarize what the (dis)advantages of this upgrade are, for us regular users who aren't into compilers? ;)

    1. By DIGITALMAN () on

      Advantage: programs become faster, GCC3 is better aligned with standards, and every one else is using GCC3 too. Disadvantage: building binaries takes more time, some "mistake" code needs to be "fixed" to work with GCC3.

    2. By thuglife () on

      For example when I installed FreeBSD 5.1 onto one of my SMP servers, the buildworld took ~150 minutes. Almost the same procedure on 4.9 took ~30 minutes. Amazing, Isn't it?

      1. By Anonymous Coward () on

        What I find amazing is that you think a buildworld on 4.9 is comparable to a buildworld on 5.1.

    3. By Jedi/Sector One () on

      GCC 3 makes MySQL 4.1 actually work because the current in-tree compiler produces totally broken code.

  2. By raiten () on

    seems they are preparing a switch (some cvs log pointing warning/error find with gcc3 in base tree before)

    that's why there is no new snapshots since Nov 1 ?

    also want to know, what was the deciding point to switch

    review from gcc summit point compilation time will be improved with 3.4 (mainly with precompiled headers) but 3.3 is only about speed of generated code.

    note: for now, i believe FreeBSD5, netbsd-current, debian/unstable has switch to gcc3.2 and the others bsd seems to want to switch quickly to 3.3

    1. By mirabile () on

      I will start believing they switch over to it
      the day the switch is done and the cvs mail
      arrives in my inbox, no sooner.

      I think they are going to import the amd64
      port, which needs this obviously.

      I've still got problems with propolice on 3.2.3
      and 3.3.x though :-(

      1. By mirabile () on

        See, I was right.

    2. By dan () on

      Theo's on Vacation and was at the conference, thus, no snapshot building right now...or so i've been told.

    3. By Marc Espie () on

      There was no new snapshot because Theo was on vacation...

  3. By the 9th goblin () on

    What about the Vitanouva compilers that are going to be released under a BSD-like license?

    They are based in the Plan9 compilers by Ken God Thompson and it would be great if OpenBSD dumped that GCC abomination and used the best (Ken's)C compilers ever created...

    Of course there will always be assholes that think that GCC's "features" are "useful"... oh, well, for them there will always be Lunix and GNU/TURD

    -- the 9th goblin

    1. By Scott () on

      Their "Liberal License" looks to be incompatible with the BSD license (specifically, the requirement to identify and attribute any changes you make).

      I really wish that companies that want to open up their source use an EXISTING "Open Source" license (i.e. GPL or BSD), rather than try to be cute and come up with their own.

      1. By Anonymous Coward () on

        I'd say that compared to the GPL it's quite damn better... and maybe if Theo asked, it could be improved a bit.

        I absolutely agree in the point about reusing exsisting licenses instead of creating your own... but oh well... as I said, IMHO it's way better than the GPL.

        -- the 9th goblin

        1. By markus () on

          we did ask before. but looks
          like 8c & friends will not
          become BSD licensed.

          1. By the 9th goblin () on

            Did you ask vitanouva? their C compilers for (native) inferno are based in 8c and friends, and aparently they are going to be released under a quite liberal license(unlike the rest of inferno, that will be/is more GPL like)

            If there is a problem with vita's compilers license I'd like to know, as I know some people near vita that were quite enthusiastic about OpenBSD using the compilers, but probably it might be more useful to contact Forsyth directly.

            -- the 9th goblin

            1. By Anonymous Coward () on

              Is it usable for ppc, m88k, hppa, m68k and sparc/64
              too or is it like Tendra that only works for a few
              I dont think anyone in the openbsd camp would settle
              for a compiler that made 75%+ of their platforms not
              being able to use it.

              1. By Anonymous Coward () on

                This compilers were originally developed by Ken God Thompson and are probably one of the most portable ever created, see for some ports, I know VitaNouva wrote a few more.

                The compilers were designed to be *fast*(build a complete plan9 system in 20 sec!) and portable, according to Ken a port to a new arch(including assembler) was estimated to take 2 weeks.

                -- the 9th goblin

                1. By Anonymous Coward () on

                  but will it be able to compile the OpenBSD source ??

                  in my experience I have found that not all C is created equal in the eyes of a compiler

                  1. By goblin () on

                    Well, it compiles what has been called "Ken's C", that many have called "the perfect subset of C", with some small extensions, that is what Ken thought C should be like. It works great, but, obviously, gcc-isms are out of the questions... but that, obviously, is not a bug, is a feature.

                    it's a bit outdated(it's from early 90ies), but will give you an idea.

                    -- the 9th goblin

                    1. By Anonymous Coward () on

                      looks like somebody is pushing for only one of the available options... oh well.

                  2. By Anonymous Coward () on

                    most of the openbsd code doesn't rely on gccisms on purpose, so it would probably be relatively easy to make it real-C.

                    ...if the compiler was under an acceptable license of course.

                    1. By Marc Espie () on

                      Actually, no, it's not that easy.
                      The kernel relies on embedded assembler in
                      critical parts, and those are a bitch to switch.

                      And fixing all those pesky little reliance on gcc stuff does take time, as we've noticed again and again: each compiler update makes us change a few details.

                      Lately, GCC has been geared towards more standardization. Thus, specific gnu features get deprecated, or are gone. Most of these are dead easy to fix, a few are not.

                      Some examples:
                      - automatic include path guessing. Gone from gcc3. Requires about ten Makefiles in src to change.
                      - K&R and ANSI prototypes mixes. GCC has some magic to make some K&R declarations work when they shouldn't. I was wondering why wdc was working, until Miod Vallat pointed the magic to me. If you remove that magic, you need to finish ansification of that code.

                      WRT C++, for better or for worse, most people need it. groff notwithstanding, there is a large number of programs in the ports tree that lots of people use.

                      1. By mirabile () on

                        As for GNU Groff, I've offered my replacement plan
                        using 4.4BSD-Alpha nroff several times, and am still
                        willing to have it going into stock OpenBSD.

                        I've not ported troff and eqn, and called neqn eqn,
                        when I started it because I knew nothing about *roff,
                        but plan to change that.

                        Some tools are missing, but I can not format papers
                        to text files with multiple columns, using col.

            2. By markus () on

              I tried and failed. Feel free
              to try.

              Being a plan9 user for years,
              i'd like to see 8c in OpenBSD. The
              code is portable and already compiles
              on OpenBSD, but we won't switch
              to a non-BSD licensed compiler.

              1. By Anonymous Coward () on


                Is it not possible to get someone to agree to license it under the LPL and then relicense it under BSD per term 3?

                If so I can try to get my university to do such.

    2. By Anonymous Coward () on

      Well if they make this move, I bet you will see a grow man cry.
      Plan9 is amazing piece of OS and their code would be such great contribution from Lucent.
      Lets hope Vita Nuova can learn from Lucent mistakes and do the right thing.
      Btw Im about to order it to take a look, but money concurrency bites soo hard... :D

    3. By grey () on

      In the past, Theo has also praised the plan9 compiler and longed for an appropriate license. That said, even if it does get released under an appropriate license, and despite even Theo's own enthusiasm over the quality of the compiler itself - I'd imagine that it'd take some time for an appropriately licensed plan9 compiler to make its way into OpenBSD just due to the nature of transitions.

      That said, I would say that in the case of that compiler, license is one of the biggest hurdles for serious contemplation; whereas Theo's opinions on Tendra seem to indicate that tcc's adoption would likely never occur.

      If memory serves, Theo and others have voiced gripes about gcc 3.x with regards to its optimization techniques being counter productive to some of the compiler targetted ProPolice inclusion of late. And of course the massively longer build times.

  4. By Anonymous Coward () on

    yay! better C++ support!

    1. By goblin () on

      C++? icky!

      -- the angry goblin

      1. By dan () on

        C++? icky!

        Say what you will, but C++ has it's uses and is out there. If there is no C++ support I don't use the platform.

        1. By Anonymous Coward () on

          Great, the "platform" sure will be better off without people like you then... or it rather end up like Lunix(sic) or Windoze? So much for people that think they can code...

          "When your hammer is C++, everything begins to look like a thumb."

          You can hit your own thumbs, thank you very much.

          -- the angry goblin

          1. By dan () on

            C++ is a tool, just like C and Java and Python and Perl. You don't know what you're talking about so you can just bite me.

          2. By krh () on

            You're rather hostile.

            Please calm down. C++ is just a language.

          3. By Anonymous Coward () on

            Please leave, troll.

          4. By Anonymous Coward () on

            Gee, what did you use to post this? Mozilla? Opera? Konqueror? Oh wait, looks like those use C++! Wow!

            What word processors do you use? KWord? Oh wait, those use C++ too! Of course l33t dudes like you don't use word processors.

            Fearrr the angry goblin.. release not your wrath on us.... NOT!

            By the way there's something you might want to take up. It's called "growing up". You might want to seriously consider it some day.

  5. By quel () on

    finally I can have a non broken optimizer for my sparc64 box

    1. By Paul () on

      GCC 3.2.3 is already used on sparc64 for most ports, has been since 3.3. This fixed alot of problems with certain ports not building.


  6. By Anthony () on

    As I understand it, there are incompatibilities between stuff compiled under 2.9.x and 3.x.y. Provided I'm correct, what does this mean for people upgrading to 3.5 when it comes out in May (or whenever)?

    I'm not too worried, the upgrade to 3.4 wasn't bad. Just curious. :)

    1. By Benny Siegert () on

      IIRC, switching from gcc 2.x to 3.x is no problem as long as you are using only C. But all C++ software needs to be recompiled because of the C++ ABI changes.

      1. By Anthony () on

        Okay, that makes sense.

        I'm not really sure how much C++ there is in an OpenBSD base system, but I would think not a great deal, and only in user land.

        I just ran a find for .cpp files in /usr/src, and it doesn't look like there's a whole hell of a lot. Of course, I don't have the expertise to say which ones are important enough to get in the way of building a bootable system that can build itself, but right this second I don't particularly care either. =P

        It'll be in May, I have more immediate concerns.

        1. By mirabile () on

          MirBSD is C++ free.

          GNU groff was the hardest part to replace.

          1. By Anonymous Coward () on

            and dos it work even ?

          2. By Anonymous Coward () on

            and does it work even ?

            1. By mirabile () on

              Would I be selling if it would not work?

              The only man page I have to distribute in a
              pre-compiled form (because nobody of us was
              lazyless enough to make a groff port, there
              is a ja-groff tho) is termcap(5).

              Everything else is done with nroff, but
              tools such as soelim are missing :-(

  7. By Anonymous Coward () on

    What about TenDRA?

    1. By Anonymous Coward () on

      from: /usr/ports/lang/tendra/Makefile

      > ONLY_FOR_ARCHS= i386
      > # supports 68k, alpha, mips, sparc as well, but
      > not ported yet

  8. By Marc Espie () on

    So far, playing with the new compiler has not been painful at all.

    It was mostly imported because it is much easier to have it in-tree to work on... the size of the diffs was rather too large.

    For the time being:
    - there are bugs in the new compiler's cpp -trad.
    - the libstdc++ isn't imported yet, and doesn't work. It's likely to be some headers issue. I haven't had time to work on it.
    - other stuff like objective-C and Fortran can wait.
    - there is no propolice in the 3.3.2 in-tree yet.

    As far as first reports go, all of src except groff compiles and works just fine on i386. Performance is less abysmal than expected (kernel actually compiles faster, and userland a bit slower (20%), which is much less catastrophic than was expected).
    Some good surprises: the rewritten preprocessor groks a language that is closer to standard C, and the resulting error messages are much improved (since the compiler front-end and preprocessor have been merged, the compiler can get to precise locations in the src and show unexpanded macros). There are a few pleasant warnings too: gcc 3.3.2 knows about t[i++] = i being a bad thing. It also seems the generated code is slightly smaller, so it may make for improved bootable media.

    As far as switching to 3.3.2 happens, should be incredibly less painless than other switches. Yes, C++ code will need recompiling. But of course, C++ libraries in the base system will get bumped.

    This won't happen overnight, though. Some platforms will probably switch earlier. As someone mentionned, sparc64 support in gcc 2.95.x is bad. And new architectures like amd64 require gcc 3.x.

    By the time 3.5 comes around, it should at least be reasonably easy to compile gcc3 and play with it. Having two available compilers means more system stability: gcc 2.95 can be used until gcc3 is completely ready. And the enhanced diagnostics of gcc3 will allow us to fix minor issues.

    Performance issue with gcc3: that beast seems to require a heck of a lot more memory to be really efficient. We also need to check how good the -O1 code is. I've been told gcc 3.3.x -O1 is roughly on a par with gcc 2.95 -O2... if that's true, then gcc 3.3.x is faster than gcc 2.95 in some settings.

    1. By Anonymous Coward () on

      this is very valuable feedback - thanks for taking the time.

    2. By mirabile () on

      Propolice is really weird. When I was using an
      external gcc 3.2.2 from ports as the system compiler,
      it worked. Then I tried updating the port to 3.3,
      and it failed.

      Next time I tried 3.3 then 3.3.1 in base, now 3.2.2,
      until I discovered that everything works if I
      disable propolice.

      I'll now try diffing the old working and the new
      tree, and look what happens.

      1. By Marc Espie () on


        Propolice in OpenBSD has undergone a lot of tests, largely courtesy of Miod Vallat. The first version that was committed in gcc 2.95 was definitely NOT production quality. There were quite a few bugs to fix.

        In fact, gcc is as weird as propolice: a large part of these issues were latent gcc bugs, that propolice did trigger, where the default code paths used in gcc did not.

        One of the things newer gcc do is have stronger internal checks. My feeling is that integrating propolice in gcc 3.3.2 should be easier than for 2.95. But of course, it's not just `put the patch in and hope it works'... If making OpenBSD was that easy... everyone can take a patch and apply it to an OS and run the resulting mix. Fixing the actual bugs after applying the patch may take some real expertise.

    3. By Andrew Pinski () on

      We know about this one, a patch by you and a PR from someone else:
      - there are bugs in the new compiler's cpp -trad.

      libstdc++ does work for me on at i686-unknown-openbsd3.1 on the mainline of gcc (see

      I wish propolice get in the mainline of gcc.

      There should be more speedups in gcc 3.4 anyway.

      Yes I know I should update to openbsd 3.4 but I have not gotten around to because I would then need to change the compiling of gcc (because of the switch to elf).

    4. By Marc Espie () on

      Following up on my own message, the libstdc++
      problem has been fixed, it was in crt0.o, of all things.

      Except for propolice, gcc 3.3.2 looks fine. I've been rebuilding my whole system with it, and I'm down to 75 ports to fix before everything works.

      That's on i386, minor other fixes on other arches are expected, of course.

      But still, it's looking good.

Latest Articles


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