Re: [PATCH v4 00/11] [PR gdb/14441] Support C++0x rvalue references in gdb

[Pedro Alves <palves@redhat.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
> 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