On 10/13/2017 10:26 AM, Richard Biener wrote: > On Fri, Oct 13, 2017 at 2:40 AM, David Malcolm <dmalc...@redhat.com> wrote: >> From: Trevor Saunders <tbsaunde+...@tbsaunde.org> >> >> I had a go at updating Trevor's unique_ptr patch from July >> ( https://gcc.gnu.org/ml/gcc-patches/2017-07/msg02084.html ) >> >> One of the sticking points was what to call the namespace; there was >> wariness about using "gtl" as the name. >> >> Richi proposed (https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00155.html): >>> If it should be short use g::. We can also use gnu:: I guess and I >>> agree gnutools:: is a little long (similar to libiberty::). Maybe >>> gt:: as a short-hand for gnutools. >> >> Pedro noted (https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00157.html): >>> Exactly 3 letters has the nice property of making s/gtl::foo/std::foo/ >>> super trivial down the road; you don't have to care about reindenting >>> stuff >> >> Hence this version of the patch uses "gnu::" - 3 letters, one of the >> ones Richi proposed, and *not* a match for ".tl" (e.g. "gtl"); >> (FWIW personally "gnu::" is my favorite, followed by "gcc::"). >> >> The include/unique-ptr.h in this patch is identical to that posted >> by Trevor in July, with the following changes (by me): >> - renaming of "gtl" to "gnu" >> - renaming of DEFINE_GDB_UNIQUE_PTR to DEFINE_GNU_UNIQUE_PTR >> - renaming of xfree_deleter to xmalloc_deleter, and making it >> use "free" rather than "xfree" (which doesn't exist) >> >> I also went and added a gcc/unique-ptr-tests.cc file containing >> selftests (my thinking here is that although std::unique_ptr ought >> to already be well-tested, we need to ensure that the fallback >> implementation is sane when building with C++ prior to C++11). >> >> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, >> using gcc 4.8 for the initial bootstrap (hence testing both gnu+03 >> and then gnu++14 in the selftests, for stage 1 and stages 2 and 3 >> respectively). >> >> I also manually tested selftests with both gcc 4.8 and trunk on >> the same hardware (again, to exercise both the with/without C++11 >> behavior). >> >> Tested with "make selftest-valgrind" (no new issues). >> >> OK for trunk? > > Ok if the gdb folks approve
The new tests looks good to me. [ The class too, obviously. :-) ] (and will change to this version). GDB used this emulation/shim in master for a period, but it no longer does, because GDB switched to requiring C++11 (gcc >= 4.8) instead meanwhile... I.e., GDB uses standard std::unique_ptr nowadays. GDB still uses gdb::unique_xmalloc_ptr though. Might make sense to switch to using gnu::unique_xmalloc_ptr instead. GDB does have an xfree function that we call instead of free throughout (that's where the reference David fixed comes from). We can most probably just switch to free too nowadays. Also, gdb nowadays also has a gdb::unique_xmalloc_ptr<T[]> specialization that this patch is missing (because the specialization was added after switching to C++11): [pushed] Allow gdb::unique_xmalloc_ptr<T[]> https://sourceware.org/ml/gdb-patches/2017-08/msg00212.html So we'd need that before switching. I don't recall off hand whether it's easy to make that work with the C++03 version. Thanks, Pedro Alves
