From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28183 invoked by alias); 11 Apr 2012 17:08:54 -0000 Received: (qmail 28167 invoked by uid 22791); 11 Apr 2012 17:08:50 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Apr 2012 17:08:37 +0000 Received: by lbky2 with SMTP id y2so898534lbk.20 for ; Wed, 11 Apr 2012 10:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=C2Sbj4+dB38stnPXl7hDTc/TDoQv1IWfNdSReRfgqZY=; b=eljrOQK2Py4e3Wkfm7BDHW84V9mkuvALFaUaTZfgYg6xugLbcMst0QxUdEWNCfT4Tn rFm2b+Utvrb0GOYcbe8XM8tfiiF4r4A3Z5Go4UoZm1YevuO1xYPPE3K422BnDgbN4/22 +HV91OnqEo8kSmxrEbDOO+DLIyJEkv3MVdUSX/eeKG1xwKzExCTmOu6vn6zHHZn6MgxR 1snQKA8qWV9+pcH4GHI9HoZw2thwJpAF/MTAW6Ic0Uw8tY+UHJ5Xrk803SzhNPrL7BcM woy1vPzgQgNYWb59DB8Uqw9Aan8uFfWC3ric/B2W1XFVfu2+Uns07qn7DZa11j2Fvz5V HqOw== Received: by 10.152.129.137 with SMTP id nw9mr18872001lab.48.1334164115268; Wed, 11 Apr 2012 10:08:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.129.137 with SMTP id nw9mr18871978lab.48.1334164115086; Wed, 11 Apr 2012 10:08:35 -0700 (PDT) Received: by 10.152.4.233 with HTTP; Wed, 11 Apr 2012 10:08:35 -0700 (PDT) In-Reply-To: <4F857A44.4030202@codesourcery.com> References: <4F7B356E.9080003@google.com> <87lim3p8pv.fsf@catnip.gol.com> <4F84B448.4090208@codesourcery.com> <201204110127.30744.ebotcazou@adacore.com> <20120411070150.GM6148@sunsite.ms.mff.cuni.cz> <4F857A44.4030202@codesourcery.com> Date: Wed, 11 Apr 2012 17:08:00 -0000 Message-ID: Subject: Re: Switching to C++ by default in 4.8 From: Xinliang David Li To: Bernd Schmidt Cc: Gabriel Dos Reis , Jakub Jelinek , Eric Botcazou , gcc@gcc.gnu.org, Miles Bader , Torvald Riegel , Richard Guenther , David Edelsohn , Diego Novillo Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnQLDpCWXEvRW61MRZUOHHwQo5VcVZjry5e4nvv6IWeHE+iHUelalQhx84Uu0sP/575BsMD3Tip/Lm8B1dWgz+SfXRPCeH5VNLEDcxxxfjJfpq2AmolNFXOoYn1LJPoSmTnLIXG 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: 2012-04/txt/msg00433.txt.bz2 Mostly agreed. In particular, the discussions should be more concrete -- instead of voting on moving everything to C++ which can create a huge chaos, we should first carefully partition the components that are candidates for the migration (as mentioned by Richard). For instance, 1) core APIs a) tree based b) GIMPLE c) RTL 2) Call Graph component 3) Utility (vec, hash etc) 4) IR streamer and reader 5) IR text dumper 6) optimization driver and pass manager 7) Alias manager 8) Loop managers etc 9) Global Symbol table (do we even have one other than varpool ?) 10) Type table (non existing) 11) Local symbol table (almost non existing) 12) Bitwise data flow framework 13) target model 14) ... and *) CPP and parser (should I mention Clang? :) ) The direction for each component can be voted and the migration plan and roadmaps can also be determined before hand. For C++ifying any component, the owner/driver needs to come up with detailed proposal first. There should also be some new style guidelines. For instance, when migrating to STL container classes, should they be used in 'raw' form, or some kind of GCC style wrapper classes are defined, etc. thanks, David On Wed, Apr 11, 2012 at 5:34 AM, Bernd Schmidt wrote: > On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote: >> I have been having difficulty following the twists and the turns and >> the goal post moving. >> Are you essentially requiring to see GCC rewritten in C++ before we >> switch to C++? > > Frankly, despite all this discussion, we still don't really know what > the people who insist on a C++ conversion actually want to do. We've > seen trivial suggestions like rewriting vec.[ch], which isn't really > going to make a big difference in the grand scheme of things, but > everything else has remained vague. At the GCC gathering last year we > saw a presentation which made me feel like language features had just > gone in search of possible applications, which doesn't fill me with a > lot of confidence either. > > So yes, I would like some significant part rewritten in the way the C++ > folks would like to see it, so we can actually judge what we will get. > And that's moving my personal goal post from "hell no" somewhere closer > to what the C++ proponents would like. > > The incremental approach (tearing down the barrier of stage1 being > compiled in C first and then getting things in piecewise) may seem like > a path of less resistance, but we can't afford to have a thread like > this for every change, and I wouldn't like to see us decide after 100 > patches that the end result sucks and we have to either live with it or > revert the lot. > > IMO, gimple might be worth trying to convert, since it's the newest code > in gcc and presumably already half-way to what people consider a > "modern" style (lots of annoying little functions that get in the way > while debugging). > > But I suspect that when such a branch has been done, it will still come > down to personal preference as to which variant is best. This is why I > still think the whole thing is deeply misguided, as it's not about > objective technical issues, but merely about language preferences, and > everyone has a different one. You can't match everyone's taste in a big > project, and thus real developers have to adapt to a project, not the > other way round. Discussions like this are a toxic distraction from real > work. > > IMO it would be best if we could find a majority of global reviewers to > speak out and say once and for all "no, this just isn't happening", so > we can drop all this nonsense and get back to improving the compiler for > users. The second best thing would be to have a branch with actual work > done for us to consider. > > > Bernd