From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53098 invoked by alias); 11 Oct 2016 17:41: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 53081 invoked by uid 89); 11 Oct 2016 17:41:16 -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=one's, health, efficiently, Think 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 17:41:06 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 2A1E77F7B6; Tue, 11 Oct 2016 17:41:05 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BHf13p009978; Tue, 11 Oct 2016 13:41:02 -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> Cc: brobecker@adacore.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <4d49eb8f-5a0c-1e7e-d082-1a224179184f@redhat.com> Date: Tue, 11 Oct 2016 17:41: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: <83a8eadds7.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00271.txt.bz2 On 10/11/2016 05:57 PM, Eli Zaretskii wrote: >> That's a misunderstanding. Full C++11 support is available >> in gcc 4.8 already. > > Yes, I know. I'm just envisioning that once we require to build GCC, > we will soon require a new enough version of it. Like Joel says: That still sounds like a misunderstanding, because we're not requiring that you build GCC. We're talking about requiring C++11 support. There's a difference. If you don't have a compiler that supports C++11, _then_ you'd have to build one. That is, we're mainly talking about the trade off between getting access to C++11 and how that would improve the codebase and maintainability vs convenience of getting a new gdb built on an older system with an old system compiler. > >> 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. > > I see where it's going, and I don't like it. We will make it hard on > users to build GDB. Just 7 months ago all you needed was a C90 > compiler, and look where we are now. There's no sekrit conspiracy here. We all want gdb to succeed, don't we? All we're talking about is being able to use features that our friends on the gcc side have been working hard at making available to users, because well, they're actually useful. Of course there's a balance between wanting to use the latest features, and waiting until compiler availability is reasonably widespread. > >> I believe it's easy to find binary mingw gcc's of (at least) that >> vintage easily, for both mingw and mingw-64. > > If we stay with 4.8 for long enough, I have no problem. But we must > record this decision somewhere and stick to it, because otherwise it > will be one more domino to fall, and soon enough. Yes, of course if we move forward with a requirement change we'll document it. It'll naturally end up reevaluated at some point, maybe years from now. The jump from C++03 -> C++11 is _huge_. C++11 -> C++14 not that much. > >> I don't expect anyone to _have_ to build any mingw compiler to be able >> to build gdb for mingw. > > 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. > >> 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. > > How's above not requiring 6.x? "Until someone writes a patch that > make gdb's build system enable C++11 support with gcc < 6" one must > have 6.x, or some code will not work or be unavailable for them, > right? (And isn't there confusion between gnu++14 and C++11?) The code still works with older gccs, and just as efficiently. I'll make an analogy. Think of it as if GCC 6.x enabled some useful warning flag by default that used to be disabled by default. Until someone enables the warning on older GCCs that support it, some styles of code we don't want to allow compile successfully, while with 6.x, we get a hard error due to -Werror. So code smells that might get into the tree because they were only tested against an old GCC will will be caught quickly by whoever next builds gdb with a newer GCC that enables the warning by default. The C++11-only code in question that I'm proposing is just what enables the "warning". The C++03 version of the same code does not trigger any "warning", but it still runs. > Maybe you are 110% right; all I know is that these C++ surprises > started pouring on us with increasing rate without any prior > discussion, that's all. First, it's not true that these C++ changes have not been planned. They've been part of the plan ever since the very beginning. See here, step 5 of the original version of the plan I originally circulated in 2014: https://sourceware.org/gdb/wiki/cxx-conversion?action=recall&rev=1 Current version is here: https://sourceware.org/gdb/wiki/cxx-conversion#Transition_plan Note the not-done-yet bullet points in step 8 (step 5 in rev 1). That's exactly what's going on right now. I've also discussed the next steps of the transition on my Cauldron talk this September, though that was indeed recent: https://gcc.gnu.org/wiki/cauldron2016#Slides.2C_Videos_and_Notes Still, that's just rehashing what was already planned. But truth be told, I wasn't expecting patches to appear so fast either! Most of my C++ patches had been on the "enablement" form thus far, with the bigger ones in sourceware branches. But if people are willing to spend the effort to contributing nice C++ conversion series (which is awesome, IMO), that means they care significantly about the health of the codebase and the project, and thus I'll try to review those patches quickly, in order to keep the contributor's motivation alive. So I see the recent rush as a _good_ thing. > > But I don't want to argue about C++, that was just an example of a > slippery slope similar to what I fear will happen once we require a > new enough GCC to be able to compile GDB. I think that would be a bad > mistake. Again, no one's proposed that. Heck, until today I was under the impression that gcc 4.8 was too new and had assumed proposing to require that for C++11 would be out of question. But I'm very happy to learn that I've been mistaken! Thanks, Pedro Alves