No April Foolery: The Portable C Compiler version 1.0 was released on April 1st!
As with so many things BSD, this project proves that good code is timeless and can benefit from literally generations of review. It can build the majority of the BSD base systems (C++ code aside) and is undergoing continuous improvement.

that's something that always intrigued me..
there are many C++ compilers, but all just compile down to intermediate code, not C. Given the difficulty of making a C++ compiler, i'm surprised that there isn't a "generic" C++ -> C frontend that can be used with the plenty of C compilers available.

C++ was originally implemented via translation to C using a compiler called Cfront. See Wikipedia for more information: https://secure.wikimedia.org/wikipedia/en/wiki/Cfront . That article references a proprietary compiler project that I had not heard of before called Comeau C/C++ which apparently does still use the strategy of compiling C++ by going through C.

I think the problem is that it is useful for the compiler to know about C++'s features later on in the compiler pipeline. Converting them all to C probably makes the compiler harder to write and loses optimization opportunities.

A preprocessor is, to quote wikipedia, "a program that processes its input data to produce output that is used as input to another program". You still have to do all the hard work of parsing the code and generating the appropriate IR. At this point you'll have written a compiler frontent, so you might as well stick LLVM at the backend and emit machine code (instead of generating C and then compiling that with PCC). C++ especially is notoriously difficult to parse, so it doesn't really make sense to write a C++ to C compiler.

PCC is somewhat tied to OpenBSD. OpenBSD is actually working on eliminating all C++ from their basic tree. For example, they just got rid of groff for that very reason and replaced it with their own man-page preprocessor.

AFAIK Anders Magnusson (main developer of PCC) started revisiting old code of PCC after experience with porting NetBSD to PDP-10 (KLH10 emulator to be specific). Most problems with porting were related to GCC, not NetBSD itself.

Most work on mdocml (which replaced groff in OpenBSD) were done by Kristaps Dzonsons - NetBSD developer. NetBSD had even Google of Summer Code program related to mdocml.

Nerveless people from OpenBSD had great impact on both projects. Many BSD projects those days are maintained by more than one community.

The version number is version 1.0 of the modern revival. The original versions were more tied to the version of Unix that they shipped with than anything else.

Anyway, I don't really see the point of this. Yes it's small and portable and runs quickly, but it can't really compare to the output quality of GCC or Clang/LLVM. The idea of a compiler that runs superfast but makes slower binaries seems a bit odd.

Clang/LLVM is not released under the GPL. I think it is released under the University of Illinois/NCSA Open Source License.
see http://llvm.org/docs/DeveloperPolicy.html#license for more information on Clang/LLVM licensing. Oh the other hand what's wrong with the GCC using the GPL unless you want to make a commercial compiler?

GPLv3 is the issue. None of the BSDs can use GPLv3 sources in their own source tree.

Thus, for example, FreeBSD is stuck at GCC 4.2.1 and the accompanying versions of the binutils stack. Which is why there's a big push on to get CLang up-to-snuff, and get the source tree compilable and self-hosting on CLang. (Note: this is only applies to the compiler toolchain shipped as part of FreeBSD; users are free to install any version of GCC from the ports tree and use that for their own software projects.)

Which reads like absolute FUD to me. I've never heard of any case of a product being denied FCC licensing because the end user could change the software. Nor any product suffer "increased support costs" due to people modifying the webserver on a device.

I once preferred FreeBSD to Linux, but I see know with GPV3 that they are more interested in providing freedom to Companies, than individuals. There is no reason why my FreeBSD Desktop should suffer (worse performance from PCC compiled binaries) because some nitwit wants to throw it in a box and sell it as a media server.

Well I guess there is debian BSD, that will still use GNU userland, and probably prefer GCC licensed by GPL 3.

I once preferred FreeBSD to Linux, but I see know with GPV3 that they are more interested in providing freedom to Companies, than individuals. There is no reason why my FreeBSD Desktop should suffer (worse performance from PCC compiled binaries) because some nitwit wants to throw it in a box and sell it as a media server.

And where do you see any of the above happening? Where do you see PCC even being considered for inclusion into the FreeBSD source tree?

Well I guess there is debian BSD, that will still use GNU userland, and probably prefer GCC licensed by GPL 3.

Firstly PCC compiles quickly and produces slower binaries so that the OpenBSD tree can be built faster on very slow machines (SPARC, m68k, VAX) ... and thus testing can commence more quickly.

Also more modern variants of GCC do not support the older archs that OpenBSD (and other BSDs may support). So pcc is a solution to this problem.

The choice to develop pcc was a pragmatic consideration not an idealistic one.

Also I do not see what the problem is about releasing code that benefits everyone including companies. It is the original developers choice as to what license they wish to release their code under. Just because you don't like it doesn't mean it is wrong.

The whole point is that when building releases for testing on older architectures such as SPARC (not SPARC64), the devs can compile the tree quicker ... thus they can bug fix, test improvements etc quicker.

Yes my Core 2 can compile the whole thing in about 20 minutes ... but it is for the older slower machines which are supported.