From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30344 invoked by alias); 4 Apr 2012 11:38:37 -0000 Received: (qmail 30335 invoked by uid 22791); 4 Apr 2012 11:38:36 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-gy0-f175.google.com (HELO mail-gy0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Apr 2012 11:38:24 +0000 Received: by ghbz2 with SMTP id z2so46305ghb.20 for ; Wed, 04 Apr 2012 04:38:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.202.38 with SMTP id kf6mr1142220igc.30.1333539503552; Wed, 04 Apr 2012 04:38:23 -0700 (PDT) Received: by 10.42.228.200 with HTTP; Wed, 4 Apr 2012 04:38:23 -0700 (PDT) In-Reply-To: <4F7C2E74.6010501@google.com> References: <4F7B356E.9080003@google.com> <4F7C2E74.6010501@google.com> Date: Wed, 04 Apr 2012 11:38:00 -0000 Message-ID: Subject: Re: Switching to C++ by default in 4.8 From: Richard Guenther To: Diego Novillo Cc: Gabriel Dos Reis , David Edelsohn , gcc Content-Type: text/plain; charset=ISO-8859-1 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: 2012-04/txt/msg00093.txt.bz2 On Wed, Apr 4, 2012 at 1:20 PM, Diego Novillo wrote: > On 4/4/12 5:06 AM, Richard Guenther wrote: > >> Btw, I think we should only start forcing C++ when 1) there is a >> branch/patch out >> that shows benefit from using C++. =A0I previously mentioned that I'd li= ke >> to see >> 2) a patch that _properly_ wraps a C++ class for consumption by our >> garbage >> collector (thus, not a hack that works for a specific case but >> infrastructure >> that we think will work for _all_ cases, including libstdc++ container >> use). > > > My idea was to start with something like converting VEC() which would > require dealing with GC. > > I did not intend to make the conversion and the switch as a single > operation, however. =A0Seemed like too much to change in a single patch. > > >> So - I'll veto the switch unless I see 1) and 2). =A01) and 2) can be >> combined >> by transitioning vec.h to a C++ template class, with proper GC support. >> (not sure that I can veto anything - heh) I think vec.h is the canonical example of something that we agree on that using C++ is an improvement and a case where we have to get GC support right. If you say the changes doing GC "right" and transforming vec.h are too big to be done together, then well. You only know if you did things right if you have both the "new" GC and a user (vec.h in C++). So yes, maybe too big for a patch but not too big for a branch (where you could merge the GC infrastructure changes separately from the vec.h change). But both need to be developed together. Oh, and did we address all the annoyances of debugging gcc when it's compiled by a C++ compiler? ... Richard. > Well, none of us can, really. =A0Except maybe RMs in the context of relea= se > branches. > > > Diego.