From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9288 invoked by alias); 31 Jul 2011 22:56:31 -0000 Received: (qmail 9279 invoked by uid 22791); 31 Jul 2011 22:56:30 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail1-relais-roc.national.inria.fr (HELO mail1-relais-roc.national.inria.fr) (192.134.164.82) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 31 Jul 2011 22:56:16 +0000 Received: from afontenayssb-151-1-40-125.w83-114.abo.wanadoo.fr (HELO laptop-mg.local) ([83.114.90.125]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2011 00:56:13 +0200 Date: Sun, 31 Jul 2011 23:20:00 -0000 From: Marc Glisse Reply-To: gcc@gcc.gnu.org To: Ian Lance Taylor cc: gcc@gcc.gnu.org Subject: Re: PATCH RFA: Build stages 2 and 3 with C++ In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-7 Content-Transfer-Encoding: 8BIT 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-07/txt/msg00524.txt.bz2 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