Re: Compiling GCC with g++: a report

[Zack Weinberg <zack at codesourcery dot com>]

On Mon, 2005-05-23 at 01:15 -0500, Gabriel Dos Reis wrote:
> 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++).

These results are very interesting.

As a general observation: A lot of the things you have found to be
problematic, are in fact preferred idioms for C code.  For instance,
no standard-C programmer would ever write an explicit cast on malloc's
return value.  I think that we are losing something, if only in
readability, if we restrict our code to the subset of C which is also
correct C++.  Now, if we were migrating to C++, that would be okay,
because we would (eventually) get all of the additional expressive power
of C++ in exchange.  However, if we're not migrating to C++, I'm opposed
to the inclusion of patches that restrict our C code to the subset which
is correct C++.  Furthermore, as I've said before, I support migrating
to C++ -- but only if the C++ ABI and libstdc++ soname are first
permanently frozen.  If we do not do that first, we risk being trapped
into a situation where we need specific versions of GCC to compile
specific newer versions of GCC, which would be a Bad Thing.

The C++ ABI seems to be stable at this point, but there is not yet
consensus that it will never again be changed.  The libstdc++ team is
currently developing yet another new, incompatible version, so I see no
hope for a permanent freeze of its soname in the near future.  Thus,
while you've discovered some interesting things by trying this, I don't
think C++ compatibility patches should be applied now.

Having said that, some comments on the problems you have found:

> 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.  

Being allowed to do this is very important.  Some enumerated types are
to be treated as opaque outside a very narrow context; the only way to
do that in C is to have (a typedef of) unsigned int as the visible type,
and only declare the enumerated type in the context where it's allowed
to be used.  I want to see more use of this idiom, not less; for
example, 'enum machine_mode' ought to be a black box to almost the
entire compiler.  I'd be delighted to hear of a more C++-friendly way to
code this.  Naturally, where the constant is _not_ opaque outside of a
defined context, but is part of an interface (as your examples seemed to
be), not using it is just sloppy.

> 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).

Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike.  Patches to add 'static' to such functions (AND MAKING NO OTHER
CHANGES) are preapproved, post-slush.

> 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. 

Presumably such constants are declared in some header file, with
external linkage.  It would be better to make that declaration visible
at the point of definition, rather than marking up the declarations with
'extern'.

> 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!

Ugh.  Where do we do that?  I will suggest, when you find these, that
you tack "_s" on the end of the tag-name; that doesn't conflict with
POSIX, and should require fewer changes elsewhere in the code.

zw