This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]