Slashdot Mirror


GCC Compiler Finally Supplanted by PCC?

Sunnz writes "The leaner, lighter, faster, and most importantly, BSD Licensed, Compiler PCC has been imported into OpenBSD's CVS and NetBSD's pkgsrc. The compiler is based on the original Portable C Compiler by S. C. Johnson, written in the late 70's. Even though much of the compiler has been rewritten, some of the basics still remain. It is currently not bug-free, but it compiles on x86 platform, and work is being done on it to take on GCC's job."

5 of 546 comments (clear)

  1. Re:Not for NetBSD for sure by Aladrin · · Score: 4, Informative

    This got modded funny, but I'm sure it deserves insightful instead.

    GCC compiles on a LOT of different architectures. Does PCC? Does it do as good a job at compiling? Can we plop our current GCC-compiled source on PCC and have it compile without huge headaches?

    And what about these bugs that are even referenced in the summary? How could it POSSIBLY supplant GCC if it's that buggy? In fact, how could it have supplanted GCC if it hasn't taken GCC's place AT ALL yet?

    Try these headlines:

    GCC Compiler Finally Has 'Free' Competition
    New Compiler To Supplant Gnu Compiler?
    Battle of the licenses: Does the license of your compiler MATTER AT ALL!?

    --
    "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
  2. Re:Why? by TheRaven64 · · Score: 4, Informative
    License aside, the biggest benefit is that it's small. The OpenBSD (for example) base system is a self-contained operating system, including everything required to build it from source. It has the following requirements from its compiler:
    • Must compile C code (GCC does this).
    • Must support all of the platforms OpenBSD targets (GCC has a habit of dropping support for various platforms).
    • Must be easy to add new backends for new architectures (GCC makes this really hard).
    • Must be easy to audit for security (GCC is a tangled mess).
    Maybe a few I've missed. GCC is like Linux; it's a fairly good solution for a lot of problems, but it's rarely the best solution for any given problem. PCC is a better fit for the needs of the OpenBSD base system.
    --
    I am TheRaven on Soylent News
  3. not every architecture by DreadSpoon · · Score: 4, Informative

    The biggest reason for the new compiler (despite the jackass article submitter's position) is that GCC does *NOT* support every architecture. GCC drops architectures frequently as the core contributors lose interest, which hurts OSes like NetBSD that try to support more than the mainstream architectures. NetBSD relies on a combination of GCC 2, 3, and 4 to compile the OS on all of the architectures it supports.

    The idea with PCC is not that it will be BSD licensed (nobody really gives a fuck what license the compiler is under), but that it will be supported directly by the BSD community, including the NetBSD hackers who have their bazillion architectures to support.

  4. sensationalist bullshit yet again by DreadSpoon · · Score: 5, Informative

    First: PCC has not YET supplanted GCC. The BSDs are hoping it will in the future.

    Second: The biggest attraction of PCC is NOT the license. The article submitter who stated otherwise is a jackass.

    Third: There are techical reasons why GCC is actaully unusable by some BSDs, such as NetBSD, which aims to support many architectures that GCC has dropped. NetBSD uses a combination of GCC 2, 3, and 4 to compile all of its different architectures. The NetBSD developers would rather have a single compiler that handles them all. Obviously PCC is nowhere near that level yet, of course.

    Fourth: GCC politics are a pain in the ass for many BSD developers who just want to submit patches to a compiler without the overhead of GNU's policies and GCC's management.

    Fifth: GCC produces crappy code more often than anyone would like. GCC bugs are far from unheard of, performance of generated code is often unpredictable between releases, and in many less commonly used architectures or sources GCC will produce incorrect code. Yes, these cases are very rare, but the BSD folks have hit the problem often enough for it to be a concern. PCC, being simpler and less bloated with cruft from multiple rewrites of the internals will hopefully produce correct and predictable code more often than GCC.

    Sixth: PCC actually works today. It can compile most of the NetBSD userspace, as I recall, and the kernel will be ready to roll soon after some inline assembler problems are fixed. This isn't some theoretical hacky project - it works right now. It's not ready to replace GCC just yet, by any means, but it's a lot more than some Slashdotters seem to think it is.

  5. Re:"Nothing for you to see here" indeed... by synthespian · · Score: 4, Informative
    Here's the content (just so it stays in this Slashdot thread and gets archived here).

    Re: BSD Licensed PCC Compiler Imported (mod 21/25)
    by Marc Espie (213.41.185.88) (espie@openbsd.org) on Sun Sep 16 13:28:48 2007 (GMT)
                > > I am saying think this through and carefully. Rewriting a giant suite of programs just because you don't agree with the philosophy behind it sounds awful to people who have no stakes in BSD licenses.
    >
    > It's not just the licence that is a concern about the GCC suite, it's dropping support for hardware that OpenBSD supports, it's fluctuating compilation quality and it's licence are all matters for concern to users.

    The licence is just the top of the iceberg.

    GCC is developed by people who have vastly different goals from us. If you go back and read the GCC lists, you'll notice several messages by me where I violently disagree with the direction it's following. Here is some *more* flame material.

    - GCC is mostly a commercial compiler, these days. Cygnus software has been bought by redhat. Most GCC development is done by commercial linux distributors, and also Apple. They mostly target *fast* i386 architectures and PowerPC. A lot of work has been done on specmarks, *but* the compiler is getting bigger and bigger, and slower and slower (very much so).

    - GCC warnings are not *really* useful. The -Wall flag shows many right things, and quite a few wrong issues.

    - There is a lot of churn in GCC which ends up with it no longer supporting some architectures that are still relevant to us.

    - The whole design of GCC is perverted so that someone cannot easily extract a front-end or back-end. This is broken by design, as the GPL people do believe this would make it easier for commercial entities to `steal' a front-end or back-end and attach it to a proprietary code-generator (or language). This is probably true. This also makes it impossible to write interesting tools, such as intermediate analyzers. This also makes it impossible to plug old legacy back-ends for old architectures into newer compilers.

    - As a result, you cannot have the new interesting stuff from newer GCC without also losing stuff... every GCC update is an engineering nightmare, because there is NO simple choice. You gain some capabilities, and you also lose some important stuff.

    - it's also very hard to do GCC development. Their branching system makes it very likely that some important work is falling between the cracks (and this happens all the time). If you develop code for GCC, you must do it on the most recent branch, which is kind of hard to do if your platform is currently broken (happens *all the time* if you're not running linux/i386). Even when you conform, it's hard to write code to the GNU coding standards, which are probably the most illegible coding guidelines for C. It's so obvious it was written by a lisp programmer. As a result, I've even lost interest into rewriting and getting in the GCC repository a few pieces.

    - some of their most recent advances do not have a chance to work on OpenBSD, like preparsed includes, which depend on mmap() at a fixed location.

    - there are quite a few places in GCC and G++ where you cannot have full functionality without having a glibc-equivalent around.

    - some of the optimisation choices are downright dangerous, and wrong for us (like optimizing memory fills away, even if they deal with crypto keys).

    - don't forget the total nightmare of autoconf/libtool/automake. Heck, even the GCC people have taken years to update their infrastructure to a recent autoconf. And GCC is *the only program in the ports tree* that actually uses its own libtool. Its configuration and reconfiguration fails abysmally when you try to use a system-wide libtool.

    I could actually go on for pages...

    I've actually been de facto maintainer of GCC on OpenBSD for a few years by now, and I will happily switch to another compiler, so frustrating has been the road with GCC.
    --
    Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts