From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122755 invoked by alias); 19 Apr 2016 15:51:43 -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 122734 invoked by uid 89); 19 Apr 2016 15:51:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=evils, feeling, hardcoded, HX-Gm-Message-State:AOPr4FX X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 19 Apr 2016 15:51:36 +0000 Received: by mail-wm0-f68.google.com with SMTP id n3so6307826wmn.1 for ; Tue, 19 Apr 2016 08:51:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:date:message-id:subject:from:to:cc; bh=MT+vdEW1QbfL6nw8ILmyyIQ+fCie+JMkbbtlvKAIKM0=; b=ig/zVitaeHud2x+yLNhj0SSLnbpuXGtDBjtVOdFqkLS4jKInN+GYn28sdaiGPE6DYc o78ARMjid4USvDlj3T06Rza3k+gYYgVLRXMQCRHFtBtc+90lCZJQjJuuCTGMZtisztmM iuJ3muwv7SxfGR2s36T+VPr/qMm3/6DGpKels4HEUrLZdx1mK+DqC3mG2BgIOtSVKuDy xwB5o8MvpnD/eB28DM7EZiJvV6LHdlSQ6p+GmrYkxbFeT9YoLGPZmFq/Mea6bA64fvDQ VPxKAOmgwhwMgxssEZAod79EwnNnzwEeK18QV0StAlNzu8OP8DAKB9DaOooq2TESiw+F TgaA== X-Gm-Message-State: AOPr4FX/lYekXtXo8W2eGKpwl6PDuCvg+MM5rYmg9Nm/lYL1wA3k5Rmb/rn0aYcJj4Gm/PuTmTwqGT8kqTuZLA== MIME-Version: 1.0 X-Received: by 10.28.147.135 with SMTP id v129mr23818027wmd.65.1461081093007; Tue, 19 Apr 2016 08:51:33 -0700 (PDT) Reply-To: artemiyv@acm.org Received: by 10.28.170.148 with HTTP; Tue, 19 Apr 2016 08:51:32 -0700 (PDT) In-Reply-To: <570CE0B6.8080707@redhat.com> 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> <570CE0B6.8080707@redhat.com> Date: Tue, 19 Apr 2016 15:51:00 -0000 Message-ID: Subject: Re: [PATCH v4 00/11] [PR gdb/14441] Support C++0x rvalue references in gdb From: Artemiy Volkov To: Pedro Alves Cc: Keith Seitz , "gdb-patches@sourceware.org ml" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00458.txt.bz2 Hi Pedro, sorry for the delay... On Tue, Apr 12, 2016 at 2:49 PM, Pedro Alves wrote: > 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. Yes, I agree. Adding -std=c++11 to the .exp files covering so much core functionality wasn't right. > 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? > Actually, this pattern has already been introduced: see gdb.base/nested-subp[1-3].exp and gdb.cp/enum-class.exp. The authors of these tests hardcoded the standard version in the additional_flags variable. And I think this is the best way to go here -- IMO the cost of the implementation you suggested outweighs the benefits. I understand the idea of having the rvalue ref tests and the corresponding pointer/lvalue ref tests next to each other, but that would cause too much pollution by lots of "#ifdef __cplusplus >= ..." and reduced readability. And if we group the rvalue ref tests together to make it just one #ifdef, why don't we move those tests out to a separate file in the first place? Also, using this scheme we would have to create a way to run only specific testcases twice, which doesn't look like a clean solution, or maybe we'd have to run the whole gdb.cp/* part of testsuite twice which would be unwarranted waste of time. And people who want to run all of it using C++03 and C++11 stds can do it by hand. So yeah, IMO the least of evils here would be to split rvalue reference tests to separate files and to hardcode -std=gnu++11 in the .exp files. This solution is much simpler, it keeps the source files clean, it assures that each testcase will be run once (which is not a bad thing regarding the time it takes to run the whole testsuite). What do you say? Am I missing something? Thanks, Artemiy