From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130816 invoked by alias); 20 Nov 2015 11:21:19 -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 130799 invoked by uid 89); 20 Nov 2015 11:21:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 Nov 2015 11:21:17 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 78B1F8E39B; Fri, 20 Nov 2015 11:21:16 +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 tAKBLEQx028173; Fri, 20 Nov 2015 06:21:15 -0500 Message-ID: <564F022A.10603@redhat.com> Date: Fri, 20 Nov 2015 11:21:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org, Simon Marchi Subject: Re: [PATCH 0/6] [C++] Drop -fpermissive hack, enable -Werror References: <1447864802-24016-1-git-send-email-palves@redhat.com> <564CB8EC.5000203@gmail.com> <564CBB15.7020209@redhat.com> <867fle1b5z.fsf@gmail.com> <564DE744.8030104@redhat.com> <86lh9types.fsf@gmail.com> In-Reply-To: <86lh9types.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00418.txt.bz2 On 11/20/2015 09:46 AM, Yao Qi wrote: > Pedro Alves writes: > >> Yeah, my plan here was to "lock" (*) ports to C++ mode one by one, as soon >> as they build in C++ mode. Actually, I think a negative/reverse list is even >> better. This allows keeping track of ports/hosts people really still care >> about, and, gives us an easy defined stopping point (when the list is clear). >> What would you think of this approach? > > Yes, this approach is OK to me. However, as you said, we need to > announce this on gdb@ first. Before we build GDB in C++ mode for some > hosts, we need to test it. IIRC, we didn't test GDB built in C++ > before. On my machine (x86_64 Fedora 20), C++ mode has no regressions compared to C mode. If C++ is flipped to on by default on (e.g.) x86_64 GNU/Linux, then the x86_64 GNU/Linux buildbot builders will automatically start testing in C++ mode too. If we do this, then the Fedora builder (Fedora-x86_64-cxx-build-m64) that is specifically building with --enable-build-with-cxx should be flipped to build with --enable-build-with-cxx=no, to catch C mode regressions, for as long as we support C mode. > > Another thing in my mind is the release schedule. We have two months, > but people are off around Christmas and New Year. Do we want GDB 8.0 > built in C++ in default in some hosts, such as linux? I am not sure. Can't see why not. But we can always flip back to C for the release. > >> >> I should probably move this to a separate thread, push this to a branch on >> sourceware.org (to collect a better initial set of still-needs-conversion-work >> hosts, with community help) and announce the intent on the gdb@ list, for >> wider visibility/discussion. > > Yes, let's do that. OK, I'll try to find some time to do it. >> AC_DEFUN([GDB_AC_BUILD_WITH_CXX], >> [ >> + # The "doesn't support C++ yet" hall of shame. >> + case $host in >> + *-*aix* | \ >> + *-*go32* | \ >> + *-*darwin* | \ >> + *-*solaris* | \ >> + *-*nto* | \ >> + *-*bsd* | \ >> + xtensa*-*-linux* | \ > > Why do we especially exclude xtensa*-*-linux* from building in C++ mode? Just because that one I know for sure doesn't build in C++ mode yet -- I have a patch from Simon in my github C++ branch that fixes gdb/xtensa-linux-nat.c in C++ mode, which is not upstream yet. Thanks, Pedro Alves