From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7110 invoked by alias); 1 Sep 2016 18:17:44 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7101 invoked by uid 89); 1 Sep 2016 18:17:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Sep 2016 18:17:42 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 63A7E11727B; Thu, 1 Sep 2016 14:17:41 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ehxAT7N9Zlud; Thu, 1 Sep 2016 14:17:41 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3D390116CE4; Thu, 1 Sep 2016 14:17:41 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A396E42319; Thu, 1 Sep 2016 11:17:39 -0700 (PDT) Date: Thu, 01 Sep 2016 18:17:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: "gdb@sourceware.org" Subject: Re: Go C++ only Message-ID: <20160901181739.GR4538@adacore.com> References: <212bc30a-e6ad-886b-0881-8206dd91b933@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <212bc30a-e6ad-886b-0881-8206dd91b933@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-09/txt/msg00006.txt.bz2 > As last discussed, the general consensus was to make 7.12 > the last gdb version that supports building with a C compiler. > > I've been holding proposing to drop C-mode support in master > with the idea that that would help with all the bugfix > backporting going on. I've had to explain this several times > recently, as people are eager to use C++ features. Multiple > times this week, even. > > At this point the backporting rate is quite low though, so > maybe it no longer makes that much sense to hold C++ back, > at least in new code. I don't have a strong opinion, but can we perhaps try a compromise where we would be using C++ features only in new units (unlikely to be backported)? Even though the backporting rate is indeed probably low, it would still be nice to make it as easy as possible. Or is this not really a practical suggestion? -- Joel