From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82650 invoked by alias); 17 Oct 2016 23:43:35 -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 82635 invoked by uid 89); 17 Oct 2016 23:43:34 -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=6a, sooo, Hx-languages-length:2543, quicker 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; Mon, 17 Oct 2016 23:43:24 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 985E985A07; Mon, 17 Oct 2016 23:43:22 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9HNhJbc005571; Mon, 17 Oct 2016 19:43:21 -0400 Subject: Go C++11? (was: Re: [RFA 09/22] Remove make_cleanup_restore_current_ui) To: Eli Zaretskii 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> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <072d729d-8e32-024e-4aab-09f6b4d5e3d9@redhat.com> Date: Mon, 17 Oct 2016 23:43: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: <685ed94c-fd1b-6b0a-4fe0-0418966b184f@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00497.txt.bz2 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. Thanks, Pedro Alves