From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29074 invoked by alias); 1 Aug 2011 09:14:50 -0000 Received: (qmail 29066 invoked by uid 22791); 1 Aug 2011 09:14:48 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-yi0-f47.google.com (HELO mail-yi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Aug 2011 09:14:34 +0000 Received: by yib18 with SMTP id 18so3913083yib.20 for ; Mon, 01 Aug 2011 02:14:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.122.7 with SMTP id z7mr621396ybm.307.1312190074098; Mon, 01 Aug 2011 02:14:34 -0700 (PDT) Received: by 10.150.219.17 with HTTP; Mon, 1 Aug 2011 02:14:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 01 Aug 2011 09:14:00 -0000 Message-ID: Subject: Re: PATCH RFA: Build stages 2 and 3 with C++ From: Richard Guenther To: gcc@gcc.gnu.org Cc: Ian Lance Taylor Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00005.txt.bz2 2011/8/1 Marc Glisse : > 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. =A0This 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. =A0This means that the gcc installed and used by most people wi= ll >> be built by a C++ compiler. =A0This 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=3D'gcc -U__GNUC__' and CXX= =3D'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 =91cha= r*=92 > to =91int=92 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 =91unsigned int=92 to =91cpp_ttype=92 [-fpermissive] > /data/repos/gcc/trunk/libcpp/charset.c:1371:1: error: =A0 initializing > argument 5 of =91bool cpp_interpret_string(cpp_reader*, const cpp_string*, > size_t, cpp_string*, cpp_ttype)=92 [-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 (ju= st > 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 stag= e1 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.