Not really, no, Anders Magnusson had commit access to OpenBSD's CVS repository once.. but he hasn't committed since 2009.

There hasn't been any commits to pcc in OpenBSD's tree lately, It seems as if developer interest has died down a bit.. mostly due to PCC only supporting i386/amd64 primarily at the moment.

OpenBSD will probably continue using GCC until maintaining their forks of gcc2/3/4 is no longer feasible.. they can't port bugfixes from upstream GCC due to the license change to GPLv3, fixes have to be done independently or taken from other forks.

There is some C++ in Xenocara, notably Mesa. So either it will have to be rewritten or disabled, or gcc will be kept around to deal with it.

Architecture support is improving in PCC (such as MIPS, iirc) but currently not up to the OpenBSD standard either. PCC is easy to extend to new architectures—the i386 port took only a few days—but that requires someone willing to work on and maintain the compiler for that architecture…

__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems.

There is some C++ in Xenocara, notably Mesa. So either it will have to be rewritten or disabled, or gcc will be kept around to deal with it.

PCC is intended to be a system compiler. One could argue that Mesa and Xenocara are not part of the core system but provided as a convenience to users. Compiling Xenocara is usually never needed. If you need to compile Xenorara GCC could be pulled as a dependence just like it is going to be pulled for many ports. There are even ports like MPlayer that explicitly require GCC and can not be compiled with any other open or close source compilers.

Building the userland, including X, has never involved the ports tree.. and while regular users are not encouraged to build X themselves, that doesn't mean it isn't a critical component of the base system that gets built by the developers.

Building the userland, including X, has never involved the ports tree.. and while regular users are not encouraged to build X themselves, that doesn't mean it isn't a critical component of the base system that gets built by the developers.

These days it's almost discouraged NOT to install the X sets.

Then I can easily see the situation in the future in which there would be choice for OpenBSD either to completely fork X and kill C++ Mesa (and possibly some other things which might in future be written in C++) or to add support for C++ to PCC which is probably even more difficult.

For C++, it may be a moot point for PCC, from the referenced article -> . Which would likely make it even more effort for OpenBSDs non x86-related platforms.

As long as there's a good clean separation between parsers and code generators (yes, that's an extreme oversimplification), a C++ frontend shouldn't really impact the architecture-specific code generators. Perhaps I've oversimplified to the point of overlooking issues, but my understanding is that keeping the frontend and backend as separate as possible (something that gcc does a piss-poor job of) alleviates these issues.

Perhaps I've oversimplified to the point of overlooking issues, but my understanding is that keeping the frontend and backend as separate as possible (something that gcc does a piss-poor job of) alleviates these issues.

Actually this is correct, & I can vouch that one commercial i386 compiler did just this. Front-end problems were completely divorced from code generation issues.

...it's good to know that the theory matches reality (if even only sometimes) heh

Everything is fair in love & war & compiler implementation, but separation between front-end syntax checking, intermediate parse tree creation, & back-end code generation can be an easy discipline to maintain. With as many processors that gcc supports, one would think that separating out the code generation code would be a given, but I haven't looked at it, so I can only conjecture.

With as many processors that gcc supports, one would think that separating out the code generation code would be a given

GCC doesn't separate back and front ends by design!!! RMS was afraid that such a properly designed compiler would be more interested for industry to "steal" . You can find about some of similar "bright" ideas and the reasons for their implementation from various e-mail list all over the Internet.