From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8192 invoked by alias); 2 Apr 2003 02:50:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8179 invoked from network); 2 Apr 2003 02:50:27 -0000 Received: from unknown (HELO caip.rutgers.edu) (128.6.236.10) by sources.redhat.com with SMTP; 2 Apr 2003 02:50:27 -0000 Received: (from ghazi@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id VAA12000; Tue, 1 Apr 2003 21:50:26 -0500 (EST) Date: Wed, 02 Apr 2003 09:18:00 -0000 From: "Kaveh R. Ghazi" Message-Id: <200304020250.VAA12000@caip.rutgers.edu> To: gcc@gcc.gnu.org, java@gcc.gnu.org Subject: Using g++ to build java? Cc: mark@codesourcery.com X-SW-Source: 2003-04/txt/msg00062.txt.bz2 So, did we come to a conclusion about whether to use C++ in Java and how to accomplish it while bootstrapping? IMHO, the easiest solution is to arrange to compile g++ during stage1 so we are free to use it in stage2 and later for building other languages. Since we can rely on ISO C now, our first step is to get rid of gcc extensions in the g++ frontend. To achieve this and to ensure it remains so, it means we have to build cc1plus with -pedantic and squelch any problems. I tried it and got these warnings: > % .../contrib/warn_summary -cp output.log > Counting warnings in the gcc/cp subdirectory, > there are 1014 warnings in stage3 of this bootstrap. > > [...] > > Number of warning types: > 713 ISO C forbids braced-groups within expressions > 216 bit-field `???' type invalid in ISO C > 55 comma at end of enumerator list > 11 ISO C forbids use of conditional expressions as lvalues > 8 ??? format, ??? arg (arg ???) > 7 `return' with a value, in function returning void > 4 ISO C does not allow extra `???' outside of a function These all look like simple (i.e. obvious one-line) fixes. The high number results from headers repeatedly included. I.e. we don't actually have to fix 1000 spots. :-) Are there any objections to proceeding? If we're concerned about diverging from 3.3 and creating merge conflicts, I believe all of these changes will be so simple that we could safely put them in both mainline and branch. I.e. we're talking about e.g. adding `__extension__' or removing extra commas, etc. Once we get these fixed, I can test building cc1plus using solaris2 and irix6 cc to ensure it works with ISO C compilers. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu