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

[Richard Guenther <richard.guenther@gmail.com>]

2011/8/1 Marc Glisse <marc.glisse@inria.fr>:
> 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.

I think it's the only viable solution (use the full enum for a non-GCC stage1
C++ compiler).  We could help it somewhat by at least placing
enum bitfields first/last in our bitfield groups.

Any other opinions?

Btw, thanks for trying non-GCC stage1 compilers ;)

Richard.