[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: PATCH RFA: Build stages 2 and 3 with C++
From:       Marc Glisse <marc.glisse () inria ! fr>
Date:       2011-07-31 22:56:06
Message-ID: alpine.DEB.2.02.1108010008200.5578 () laptop-mg ! saclay ! inria ! fr
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]