This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFA: Build stages 2 and 3 with C++


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]