From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120255 invoked by alias); 19 Oct 2016 18:02:55 -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 118365 invoked by uid 89); 19 Oct 2016 18:02:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=002, love X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Oct 2016 18:02:44 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1bwvCM-0002nN-CR from Luis_Gustavo@mentor.com ; Wed, 19 Oct 2016 11:02:42 -0700 Received: from [134.86.105.168] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 11:02:39 -0700 Subject: Re: Go C++11? References: <1474949330-4307-1-git-send-email-tom@tromey.com> <1474949330-4307-10-git-send-email-tom@tromey.com> <2f79a489b9090701f15fc04e0017c236@simark.ca> <87y41xd0dt.fsf@tromey.com> <1f5898b8-6be9-48e6-4312-72ec90e7810e@redhat.com> <87insxmbnd.fsf@tromey.com> <2855e2ec-46dc-71b7-9943-8edaebcbef90@redhat.com> <8337k0aicw.fsf@gnu.org> <6f27db2e-4b88-b72a-5836-080c3583eb7f@redhat.com> <83r37k8ifg.fsf@gnu.org> <83lgxs8fyj.fsf@gnu.org> <9d9dca17-56a6-6c0a-44bb-efc425f24d8d@redhat.com> <83k2dc8ef4.fsf@gnu.org> <685ed94c-fd1b-6b0a-4fe0-0418966b184f@redhat.com> <072d729d-8e32-024e-4aab-09f6b4d5e3d9@redhat.com> To: Pedro Alves , Eli Zaretskii CC: , , Reply-To: Luis Machado From: Luis Machado Message-ID: <051716de-e27f-9798-e376-b6b0888159b9@codesourcery.com> Date: Wed, 19 Oct 2016 18:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <072d729d-8e32-024e-4aab-09f6b4d5e3d9@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-01.mgc.mentorg.com (147.34.90.201) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00578.txt.bz2 On 10/17/2016 06:43 PM, Pedro Alves wrote: > On 10/13/2016 04:43 PM, Pedro Alves wrote: >> On 10/13/2016 04:19 PM, Eli Zaretskii wrote: >>>> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org >> >>>> All I know right now that we sorely need an owning smart pointer. >>>> And for this particular case, I think it makes a ton of sense to go >>>> dual dialect. >>> >>> But if we agree to require C++11 starting from now, you can go ahead >>> with your patch, and don't even need the other dialect. So this >>> sounds like a win-win solution to me. >> >> Well, that'd be perfect. >> >> But as I mentioned elsewhere, I'd prefer to take a staged approach >> to C++11. I.e., have a fallback plan. My shim would actually _help_ >> with that. So the plan would span a few weeks, and it'd be: >> >> #1 - get gdb::unique_ptr in >> >> #2 - start using unique_ptr throughout (there's a ton of work >> to do here, and it go on in parallel with the remainder >> of the plan.) >> >> #3 - install the patch that switches C++11 on if the compiler supports it. >> The one I sent yesterday. >> >> #4 - see if that causes problems. fix problems. maybe revert patch >> from step #3 if problems are hard to solve quickly. >> >> #5 - flip to consider C++11 mandatory. Make configure error out >> if no C++11 compiler is found. >> >> #6 - see what workflows break (e.g., see if we need to do anything >> with some buildslaves. >> >> #6.a - if $problem, revert patch from step #5. fix whatever workflows, >> and goto #5. >> >> #7 - otherwise, after some period, start using C++11 in full. >> Remove the shim and do s/gdb::unique_ptr/std::unique_ptr/g >> throughout the code base. >> >> All the while between #1 and #7, we can progressively convert >> cleanups to use gdb::unique_ptr. Ie., we'd pipeline/paralyze >> the work. > > So from the analysis I did at [1] it seems like we're actually > clear from the buildslave's side on requiring C++11. I thought > it take longer to update the buildslaves, but MarkW was quick > and there doesn't seem to be other buildslaves that need > updating. > > Sooo.... Shall we proceed with the straw man proposal and > apply the patches at [2] (enable -std=gnu+11 on gcc >= 4.8)? > > [1] - https://sourceware.org/ml/gdb-patches/2016-10/msg00496.html > [2] - https://sourceware.org/ml/gdb-patches/2016-10/msg00336.html > > Do people feel this hasn't been sufficiently discussed? > > If we can do this now, I'll happily drop my shim in favor of > jumping to C++11 quicker! Maybe it'll find a home in gcc. :-) > > I'd love to hear feedback. I personally feel this hasn't been discussed much, but honestly it doesn't feel like discussion is going to change anything here other than create clashes of ideas. :-) I've seen this go from "You got it wrong. We're not going to move to C++11" to "So, shall we move now?" rather quickly. Nothing showed up in gdb@ either. Since we're already moving things quickly, we should probably discuss a policy to accept the next standard version and follow that from now on. My $0.02.