From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27393 invoked by alias); 6 Nov 2013 20:51:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27383 invoked by uid 89); 6 Nov 2013 20:51:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Nov 2013 20:51:47 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA6Kpcoa030095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Nov 2013 15:51:39 -0500 Received: from stumpy.slc.redhat.com (ovpn-113-132.phx2.redhat.com [10.3.113.132]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rA6KpbGU014481; Wed, 6 Nov 2013 15:51:37 -0500 Message-ID: <527AABD9.3030408@redhat.com> Date: Wed, 06 Nov 2013 21:04:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Richard Biener , Bernd Schmidt CC: David Malcolm , GCC Patches , Andrew MacLeod Subject: Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3) References: <5271CBF9.2070005@redhat.com> <1383236801-13234-1-git-send-email-dmalcolm@redhat.com> <527960A8.7030107@redhat.com> <527A21DB.301@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00648.txt.bz2 On 11/06/13 04:31, Richard Biener wrote: > On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt wrote: >> On 11/06/2013 10:31 AM, Richard Biener wrote: >>> We decided to move to C++. As part of a later discussion we decided >>> to go with a single general dynamic-casting style, mimicing the "real" >>> C++ variant which is dynamic_cast < ... >. Which resulted in >>> is-a.h. >>> >>> So yes, we've decided to go C++ so we have to live with certain >>> uglinesses of that decisions (and maybe over time those uglinesses >>> will fade away and we get used to it and like it). >>> >>> Thus, there isn't another option besides using the is-a.h machinery >>> and enabling and using RTTI. Sticking to C for gimple doesn't seem >>> to be consistent with the decision to move to C++. >>> >>> Oh, I'm not saying I'm a big fan of as_a / is_a or C++ in general >>> as it plays out right now. But well, we've had the discussion and >>> had a decision. >> >> Maybe we need to revisit it? As one of those who were not in favour of >> the C++ move, can I ask you guys to step back for a moment and think >> about - what do all of these changes buy us, exactly? Imagine the state >> at the end, where everything is converted and supposedly the temporary >> ugliness is gone, what have we gained over the code as it is now? > > as_a gains us less runtime checking and more static type checking > which is good. Absolutely. > That I agree to. Instead of fixing the less than optimal separation / boundary > between frontends and the middle-end, or fixing several other long-standing > issues with GCC we spend a lot of time refactoring things to be C++. > But that was kind of part of the decision (though I remember that we > mainly wanted to convert containters and isolated stuff, not gimple > or trees (I bet that'll be next)). That's a reasonable bet given what's already been said on this list WRT gimple. > > Of course I don't see contributors of "changes that improve gcc for its users" > now wasting their time with converting code to C++. That conversion > may slow down those people, but only so much. It'll get more interesting > with branch maintainance ... True. But that's probabl more of an artifact of the engineers involved. David (who's by far the most gung-ho on the C++ front) is fairly new to GCC and isn't really in a position right now to drive much user visible stuff. So he's doing what he can right now. jeff