Hi, I spent the week-end trying to get GCC -- mainline -- compilable (i.e. those compoenents written in C) with a C++ compiler (e.g. g++).
My summary is: It is largely doable and it is within our reach at this point of development. More specifically, I successfully got all files necessary to build a native GNU C compiler on an i686-pc-linux-gnu. Attempt to get the GNU C++ compiler through the same massage is underway (but I'm going to bed shortly ;-)). I think this project is beneficial to GCC for several reasons: (1) for testing purposes, we can use a compiler with stricter type checking. (2) there have been lots of discussions about more static typing in the data structures, but so far we haven't made anything concrete. Partly because, we need this sort of preliminary preparation of thee source tree. We can have infinite debates about the merits of such approaches, but I think a way to know is to do actual experiments and we better start making that possible now. (3) It might open the door for more contributions and foster more free software based on GCC. (4) <insert your favorite reasons why you would like to see this happen>. What I have learnt from this little experience. Well, the source code seems to have been carefully written to make sure that no lunatic (e.g. the author of this writing) will succeed in feeding a C++ compiler with GCC :-) The first resistance seems to come from the pervasive use of the implicit conversion void* -> T*, mostly with storage allocating functions. We've recently introduced C++ friendly macros in libiberty, but we have yet to take advantage of them. We should start now. (I also noted a happy confusion about the calling convention of the function [x]calloc(), but it is mostly harmless as everything "multiply nicely" in the end and we don't get burned by strict alignment issues). We should generalize the notation for GGC allocators and alloca(). The second resistance is the pervasive use of C++ keywords (e.g. new, class, template, try, catch, ...). The first three are quite frequent in the middle-end. Third, there is some "type-punning" with enums, int and unsigned int, where the middle-end (mostly) relies on implicit conversion from int to enums. That is a bit annoying but could be avoided as most of the time, we do have names for those integer constants. For example, we should be using EXPAND_NORMAL instead of 0, or VOIDmode, instead of 0, TV_TOTAL instead of 0, etc. At this point, I should also note that not implicit conversions between enums (c_tree_code <-> tree_code, or rtx_code <-> reg_note, etc.) is not supported in C++. So, we should probably arrange to make the relationship (mostly subsetting) between more explicit, as opposed to throwing in casts. Also, there are few cases where we want to iterate over all the values of enumerations. I've shamelessly used the following macros: #define NEXT(E) ((__typeof__(E)) (E + 1)) #define PREV(E) ((__typeof__(E)) (E - 1)) #define DECR(E) (E = (__typeof__(E)) (E - 1)) #define INCR(E) (E = (__typeof__(E)) (E + 1)) #define IOR(A,B) ((__typeof__(A)) (A | B)) #define AND(A,B) ((__typeof__(A)) (A & B)) #define XOR(A,B) ((__typeof__(A)) (A ^ B)) but I'm not suggesting that as real replacement; just reporting the dirty tricks I did and I'm looking for better suggestions. Fourth, it appears that we're implicilty using C99's semantics of "extern inline" in our source -- when we have a pure C90 compiler that does not understand "inline", we just #define inline to nothing so we don't get into trouble. With a C++ compiler, we're in trouble because an inline function needs to be defined in every translation where it is used. So, I either move the affected functions to "static inline" or just make then non-inline (cases are in hashtable.c and toplev.c). Fifth, there is a slight difference between "const" in C and in C++. In C++, a const variable implicitly has an internal linkage; so a C++ compiler tends to optimize it out when its address is not taken (so no storage is wasted). This is an issue for the objects automatically generated by the gengtype support machinery. The are supposed to have external linkage, so we need to explicitly say "extern" in their definitions. Sixth, there is a real "mess" about name spaces. It is true that every C programmers knows the rule saying tags inhabit different name space than variable of functions. However, all the C coding standards I've read so far usually suggest typedef struct foo foo; but *not* typedef struct foo *foo; i.e. "bringing" the tag-name into normal name space to name the type structure or enumeration is OK, but not naming a different type! the latter practice will be flagged by a C++ compiler. I guess we may need some discussion about the naming of structure (POSIX reserves anything ending with "_t", so we might want to choose something so that we don't run into problem. However, I do not expect this issue to dominate the discussion :-)) So, if various components maintainers (e.g. C and C++, middle-end, ports, etc.) are willing to help quickly reviewing patches we can have this done for this week (assuming mainline is unslushed soon). And, of course, everybody can help :-) Thanks, -- Gabriel Dos Reis [EMAIL PROTECTED] Texas A&M University -- Department of Computer Science 301, Bright Building -- College Station, TX 77843-3112