On Fri, 15 Jul 2011, Ian Lance Taylor wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1. This means that the gcc installed and used by most people will
be built by a C++ compiler. This will ensure that gcc is fully
buildable with C++, while retaining the ability to bootstrap with only a
C compiler, not a C++ compiler.
Nice step. Now that gcc can (mostly) build with g++, it would be great if
it could build with a non-gnu compiler. More precisely, with a compiler
that doesn't define __GNUC__. Indeed, the code is quite different in this
case, as can be seen trying to compile gcc with CC='gcc -U__GNUC__' and
CXX='g++ -U__GNUC__' (there are other reasons why this won't work, but at
least it shows some of the same issues I see with sunpro).
To start with, the obstack_free macro casts a pointer to an int -> error.
/data/repos/gcc/trunk/libcpp/directives.c:2048:7: error: cast from ‘char*’
to ‘int’ loses precision [-fpermissive]
Then, ENUM_BITFIELD(cpp_ttype) is expanded to unsigned int instead of the
enum, and conversions from int to enum require an explicit cast in C++,
giving many errors like:
/data/repos/gcc/trunk/libcpp/charset.c:1615:79: error: invalid conversion
from ‘unsigned int’ to ‘cpp_ttype’ [-fpermissive]
/data/repos/gcc/trunk/libcpp/charset.c:1371:1: error: initializing
argument 5 of ‘bool cpp_interpret_string(cpp_reader*, const cpp_string*,
size_t, cpp_string*, cpp_ttype)’ [-fpermissive]
Do we want to add a cast in almost every place a field declared with
ENUM_BITFIELD is used? That's quite a lot of places, everywhere in gcc...
The alternative would be to store the full enum instead of a bitfield
(just for stage1 so that's not too bad), but some comments in the code
seem to advise against it.
--
Marc Glisse
