This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v4 00/11] [PR gdb/14441] Support C++0x rvalue references in gdb
- From: Pedro Alves <palves at redhat dot com>
- To: Artemiy Volkov <artemiyv at acm dot org>
- Cc: Keith Seitz <keiths at redhat dot com>, gdb-patches at sourceware dot org
- Date: Tue, 12 Apr 2016 12:49:10 +0100
- Subject: Re: [PATCH v4 00/11] [PR gdb/14441] Support C++0x rvalue references in gdb
- Authentication-results: sourceware.org; auth=none
- References: <1457147955-21871-1-git-send-email-artemiyv at acm dot org> <1458593958-25656-1-git-send-email-artemiyv at acm dot org> <56FD89F7 dot 1020409 at redhat dot com> <20160402084706 dot GD7371 at gmail dot com> <570402A1 dot 6030600 at redhat dot com> <20160406083016 dot GA31849 at gmail dot com>
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
> 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.
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
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
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.