From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83514 invoked by alias); 12 Apr 2016 11:49:16 -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 83453 invoked by uid 89); 12 Apr 2016 11:49:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Youll, You'll, tweak, vice 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; Tue, 12 Apr 2016 11:49:13 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 4458981102; Tue, 12 Apr 2016 11:49:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3CBnAw2020115; Tue, 12 Apr 2016 07:49:11 -0400 Subject: Re: [PATCH v4 00/11] [PR gdb/14441] Support C++0x rvalue references in gdb To: Artemiy Volkov References: <1457147955-21871-1-git-send-email-artemiyv@acm.org> <1458593958-25656-1-git-send-email-artemiyv@acm.org> <56FD89F7.1020409@redhat.com> <20160402084706.GD7371@gmail.com> <570402A1.6030600@redhat.com> <20160406083016.GA31849@gmail.com> Cc: Keith Seitz , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <570CE0B6.8080707@redhat.com> Date: Tue, 12 Apr 2016 11:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160406083016.GA31849@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00241.txt.bz2 On 04/06/2016 09:30 AM, Artemiy Volkov wrote: > On Tue, Apr 05, 2016 at 07:23:29PM +0100, Pedro Alves wrote: >> Thanks you very much for this patch set, and big thanks to Keith >> for the review. >> >> I read the series and it looks pretty good to me. The only >> thing I'm not sure about is the hardcoding of "-std=c++11" >> in tests. GCC 6 switches to -std=gnu++14 by default, for instance, >> and I wouldn't want the tests to not cover whatever the compiler >> uses by default. Note also that that's -std=gnu++14, not the stricter >> -std=c++14 mode. Could we make the testcases gracefully skip rvalue >> reference bits using #if __cplusplus? > > Point about -std=gnu++ vs. -std=c++ taken, I'll fix it in v5. > > My idea here was to use the earliest version of the C++ standard which > supports rvalue references and compile with that, since compiling with > every version after that should produce a functionally identical > program. So I'd say for every version of GCC capable of processing (GNU) > C++11+ code we should hardcode -std=gnu++11, based on the assumption > that the supplied version of the compiler is working correctly using any > standard. > IOW I think we should be testing GDB, not GCC here. I wouldn't want to generalize that assumption: C++11 is different enough that there's even been a need to break ABI. E.g., consider a test that involves printing or passing a std::string as param in an infcall; these may behave differently depending on C++ version. The ABI tags feature added to handle the ABI break also affect namespaces, parsing, and mangling handling in GDB, and can cause issues when code is compiled in C++11 mode, but not in C++03, and vice versa. On ABI tags issues, I'm thinking of PR19436 for example. So GDB needs to be able to debug code compiled with all C++ variants. > That said, I think your approach has an advantage of letting the > testsuite pass when using an old compiler not supporting C++11. If we > should cater for those, then this consideration outweighs the ones in > the paragraph above. If not, then for the reasons given above, I think > we should leave -std=gnu++11 in place. > > WDYT? I think we need to consider the pattern being introduced here, in general. For instance -- what will we do when we decide to test something C++14/C++17...-specific and find we could do that by just doing a small tweak to .cc file? Would we bump the testcase's C++ version, losing coverage of C++11 mode? In effect, that's what happened here. The only difference is that C++03 is feeling old by now, while C++17 feels too-new. However, C++03 is not old enough to be called "ancient" and "don't care", and what feels "new" is a moving target. Also, not sure all supported compilers accept "-std=gnu++11"; we may need to try compiling with different flags. How about something around this: - Don't pass any explicit -std flag in the .exp files at all. - Make these .exp tests gracefully cope with either C++03 or C++11, by skipping the C++11-specific parts when testing with C++03. - Run tests with CXX_FOR_TARGET="g++ -std=gnu++03" - Run tests with CXX_FOR_TARGET="g++ -std=gnu++11" After this is working, we could have these affected core-functionality tests themselves automatically run with multiple languages (c++03/c++11/...) That is, basically, we could factor the testcases to move their bodies to procedures taking a language version as parameter, and then have the testcases call the procedure multiple times. Alternatively, we could split the rvalue reference testing to separate files. My feeling is that it's a bit nicer that rvalue and lval reference testing is side by side in the same tests. But that might depend on the specific testcase. You'll have a better view into this here, though. WDYT? Thanks, Pedro Alves