Thorsten Glaser wrote:

Now I retrieved a recent tarball and find gcc 3.3 "not production quality" - the tarball's fairly old though.

I'd like to ask whether, when gcc 3.3.3 or even 3.4 comes out (does anybody know approximate dates?), it's likely or not to be fully supported? Mostly, the issue is: we have an i386 and a sparc port, and gcc 3.2.3 at the moment. I don't want to write a gcc 3.2 configuration for sparc, as the 3.3 format is different (eg. with CPP_PREDEFINES), and can't take one from somewhere else and just modify it, because the gcc config still assumes it's a.out on openbsd; the openbsd people itself just started work on integrating gcc 3.3.2 into their tree (however not, unless us, as the system compiler - they still use gcc 2.95, which is just a fallback compiler for us).

The most recent gpc (alpha) relase is gpc-20030830. ATM gpc based on gcc-3.3.x is still less tested then other gpc versions. Also, there are known problems: a) in 3.3 CPP_PREDEFINES are no present. gpc has own preprocessor which on given platform is supposed to have the same set of predefined symbols as C preprocessor -- with 3.3 this is broken. b) `gpc' program contains a spec parser. This parser does not accept some constructs accepted by gcc-3.3 c) recently, there are misterious build failures on ia64 and alpha

Concerning 3.4: I have patches needed to build gpc with gcc-3.4 (december 15 version). Resulting gpc passed all its regression tests. However, besides a) and b) above there are problems with command line handling. Also, the build process requires manual corrections.

It is hard to give any specific date when the problems will be resolved. AFAIK Frank Heckenbach is in the process of rewriting preprecessor, to integrate it into the back-end, which will solve a).

Note that the impact of a) and b) depend on target platform, it can be almost harmless (on Linux) or disastrous (if platform dependent predefines are needed to choose correct code).