From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123273 invoked by alias); 12 Oct 2016 09:31:57 -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 123244 invoked by uid 89); 12 Oct 2016 09:31:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=YES, non-default, nondefault, jumping X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 09:31:46 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buFsz-0000BV-L1 for gdb-patches@sourceware.org; Wed, 12 Oct 2016 05:31:44 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buFsp-00005F-2M; Wed, 12 Oct 2016 05:31:31 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2731 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buFsn-0005Ji-1R; Wed, 12 Oct 2016 05:31:29 -0400 Date: Wed, 12 Oct 2016 09:31:00 -0000 Message-Id: <83insxc3rv.fsf@gnu.org> From: Eli Zaretskii To: "Metzger\, Markus T" CC: palves@redhat.com, brobecker@adacore.com, gdb-patches@sourceware.org, jan.kratochvil@redhat.com, simon.marchi@ericsson.com In-reply-to: (markus.t.metzger@intel.com) Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr Reply-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> <6ba388f7-1696-42db-ae92-23df79e3ba11@redhat.com> <83oa2qaxe7.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00291.txt.bz2 > From: "Metzger, Markus T" > CC: "brobecker@adacore.com" , > "gdb-patches@sourceware.org" , "Jan Kratochvil > (jan.kratochvil@redhat.com)" , Simon Marchi > > Date: Wed, 12 Oct 2016 08:11:44 +0000 > > I think we got hung up on the perceived requirement of having to build > your own GCC. The discussion got a bit too abstract and mentioning GCC 6 > as the first to default to C++11 may have been confusing in the heat of the > discussion as "GCC 6 defaults to C++11" may have been misread as "C++11 > requires GCC 6". I don't think that's what happened. In my interpretation, there are simply several issues intertwined in this discussion (which probably adds to confusion): . Should we start using C++11 features in GDB? . If the answer to the above is YES, then should we require a C++11 capable compiler as a prerequisite, or should we provide fallback code for compilers that don't support C++11, not even with a non-default command-line option? . Should we document these decisions and also decide to abide by them for some reasonably long stretch of time? > A simple and pragmatic solution would be a patch to add -std=c++11 > to GDB's compiler options. Pedro already mentioned it but I'm afraid it > got lost. > > This documents the required language version and also prevents people > from accidentally using C++14/17/?? features and not noticing it until one of > the buildbot builders complained. > > I don't think that requiring C++11 is entirely unreasonable and IMHO > preferable to back-porting standard library features. > > Should I be wrong and C++11 is really not doable, I like Pedro's patch > for giving the direction towards C++11. I would still add a compiler option > to enforce C++03 for the above reasons. Here are my opinions on the above 3 issues: . I think we should stay with C++03 for at least a year. Jumping from C90 to C++11 sounds too huge a jump. Setting the bar on C++03 would mean we still allow GCC 4.3, AFAIU, which was released in 2008. That's less than 10 years from today, so not too old IMO. We could also decide to switch to C99-level compilers, which AFAIU means GCC 4.5, released in 2010. (GCC 4.8.1, with its C++11 support, was released in 2013.) . Whatever standard we decide to aim, we should require a compiler that is capable of supporting that standard, whether with or without optional command-line switches, and we should use those switches if necessary (detected by configure) during the build. We should not provide any fallback code for compilers that don't support the standard we decide to use -- such fallback code is just maintenance headache and in the long run means code that is rarely if ever tested. . We should clearly document these decisions, and abide by them. Resetting the bar to a higher standard should IMO be based on the number of years since the release of the first GCC that supports that standard. The number of years we would like to aim for should also be a documented decision.