From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6318 invoked by alias); 11 Oct 2016 21:32:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6021 invoked by uid 89); 11 Oct 2016 21:32:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=listening, routinely, 4.x, UD:4.x X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 21:32:13 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 795896574D; Tue, 11 Oct 2016 21:32:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BLW9O8016839; Tue, 11 Oct 2016 17:32:10 -0400 Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr To: Eli Zaretskii References: <1476117992-5689-1-git-send-email-palves@redhat.com> <1476117992-5689-2-git-send-email-palves@redhat.com> <20161011121639.GE3813@adacore.com> <68fc02cb-59bc-012c-d1be-b5ed2076d6a5@redhat.com> <20161011144741.GF3813@adacore.com> <83insydifw.fsf@gnu.org> <83a8eadds7.fsf@gnu.org> <4d49eb8f-5a0c-1e7e-d082-1a224179184f@redhat.com> <831szmd977.fsf@gnu.org> <83vawybol4.fsf@gnu.org> Cc: brobecker@adacore.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <6ba388f7-1696-42db-ae92-23df79e3ba11@redhat.com> Date: Tue, 11 Oct 2016 21:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83vawybol4.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00282.txt.bz2 On 10/11/2016 09:47 PM, Eli Zaretskii wrote: >> From: Pedro Alves >> Date: Tue, 11 Oct 2016 20:19:14 +0100 >> >>> Where are the rules and decisions that we won't? >> >> What sort of rules are you expecting? > > What is the oldest version of GCC and C/C++ we are willing to support, Please reread the whole thread... That was _my_ question. IMO, that should be decided based on what's the oldest version people really care about _in practice_, and are willing to routinely test and send fixes for. Claiming we support gcc 3.4 and then not testing it is pointless. IMO, it'd be reasonable to say we only make an effort to support gcc >= 4.8. We have buildbots testing that. > and how many months/years from now we plan to reconsider that, for > example. I don't think this matters in practice. We may reconsider every week, and decide "no change" for 2 years. Or reconsider every 2 years, and decide "change". Same result. I don't when or whether in practice we'll stumble on some thing that it'd be significantly easier to write if we required a newer compiler. Time will tell. > >>>>> If you suddenly require 6.x or 7.x, they will have no choice. >>>> >>>> Well, that's (an unintended, no doubt) strawman, because no one is >>>> suggesting that. >>> >>> That's not how I read your messages. Apologies for my >>> misunderstanding, but I can show you how your words actually made that >>> sound as if you were. >> >> Please do. I'd love to learn to be clearer. > > Joel: > >> Agreed. Mostly, I was thinking of seeing if we can avoid the requirement >> to build a GCC first, if all you are interested in is actually building >> GDB. But, if C++11 is a much cleaner language overall, and its runtime >> provides some nice additions, I think it makes better sense technically >> to align ourselves to it. We've already made a huge requirement jump; >> let's just do it right all the way. That increment doesn't seem all >> that significant compared to requiring a C++ compiler. (this was in context of building a new gdb on old systems with no C++11 compiler available.) > > You: > >> It's just that gcc 6.x is the first version that has switched >> the _default_ mode for C++ to -std=gnu++14. So until someone writes a >> patch that make gdb's build system enable C++11 support with gcc < 6, >> then the C++11-only code in the gdb::unique_ptr patch that I'm proposing >> will only be active with gcc 6.1 onward. But really I'm not >> proposing to _require_ 6.x at all. I don't understand what's not clear here. Conceptually, the gdb::unique_ptr patch (this thread) does: #if HAVE_STD_UNIQUE_PTR // just use it #else // write replacement #endif The replacement is fully functional. If I push the patch in now, HAVE_STD_UNIQUE_PTR will only be true when compiling GDB with GCC >= 6.x, because G++ 6.1 targets G++14 by default, which is a superset of C++11. The replacement works with all other GCCs. It'd be possible to make HAVE_STD_UNIQUE_PTR be true with GCC >= 4.x too, but nobody wrote that patch yet. As Simon said, this is just like making use of some gnulib module to make up for some missing bit in the system's C runtime. I fail to see the worry here. It's not like I'm proposing to only enable some user-visible feature if GDB is built with some compiler versions. >> You yourself said that you have gcc 5.x available. I don't really >> understand why we're still arguing about this. > > I'm still arguing because you all but decided to declare that to enjoy > GDB to its fullest one has from now on to have GCC 6.x. GCC 6.1 was > released just this April, so it sounds too drastic to require it only > a few months later. Eli, I've repeatedly told you that that's completely false. No one is suggesting that. At this point I have to wonder whether you're not listening on purpose. Please re-read the whole thread from the top, including the series's intro. It will be amply clear that _the whole point of the patch_ is to keep supporting older compilers. Thanks, Pedro Alves