[RFC] libstdc++: Fix pretty-printing old implementations of std::unique_ptr

Jonathan Wakely jwakely@redhat.com
Mon Aug 10 17:49:18 GMT 2020

On 10/08/20 09:45 -0400, Andres Rodriguez wrote:

As it says at https://gcc.gnu.org/lists.html all patches for libstdc++
need to be sent to the libstdc++ mailing as well as the gcc-patches
list. Otherwise I won't see them, and everybody else will ignore them.

>On Tue, Aug 4, 2020 at 10:51 AM Andres Rodriguez <andresx7@gmail.com> wrote:
>> On binaries compiled against gcc5 the impl_type parameter is None,
>> which results in an exception being raised by is_specialization_of()
>> These versions of std::unique_ptr have the tuple as a root element.

The unique_ptr implementation in GCC 5 should already be handled by
the second branch which handles a tuple member:

         if is_specialization_of(impl_type, '__uniq_ptr_data') \
             or is_specialization_of(impl_type, '__uniq_ptr_impl'):
             tuple_member = val['_M_t']['_M_t']
         elif is_specialization_of(impl_type, 'tuple'):
             tuple_member = val['_M_t']
             raise ValueError("Unsupported implementation for unique_ptr: %s" % impl_type)

We have a test that's supposed to verify that printing the old
unique_ptr implementation still works:

So the right fix is to work out why that branch isn't taken, and fix
it, not add a kluge.

If impl_type is None that means the .tag field is missing, which seems
to be because the _M_t member is declared using the __tuple_type
typedef, rather than std::tuple itself.

That's fixed by the attached patch.

Tested x86_64-linux, pushed to master. I'll backport it to the
branches too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 2930 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200810/6fb957ca/attachment.bin>

More information about the Gcc-patches mailing list