[Bug libstdc++/103086] New: [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[Bug libstdc++/103086] New: [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

            Bug ID: 103086
           Summary: [11/12 Regression] std::unique_ptr printer gets
                    confused by [[no_unique_address]] in tuple
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

When using GDB 11 or 12 and GCC 11 or 12 the pretty printer for std::unique_ptr
shows the value of the deleter instead of the pointer:

$1 = std::unique_ptr<datum> = {get() = {<No data fields>}}

I filed this as https://sourceware.org/bugzilla/show_bug.cgi?id=28480 but with
Bruno's help we realised it's actually a libstdc++ printer bug.

The problem is that since std::tuple started using [[no_unique_address]] the
tuple<T*, default_delete<T>> object has two _M_head_impl subobjects, in
different base classes. That means this printer code is ambiguous:

        tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
        head_field = tuple_head_type.fields()[0]
        if head_field.name == '_M_head_impl':
            self.pointer = tuple_member['_M_head_impl']

In older versions of GDB it happened to work by chance, because GDB returned
the last _M_head_impl member and std::tuple's base classes are stored in
reverse order, so the last one was the T* element of the tuple. Since GDB 11 it
returns the first _M_head_impl, which is probably more sensible, but now the
printer gets the default_delete<T> element.

The fix is for the printer to stop using an ambiguous field name and cast the
tuple to the right base class before accessing the _M_head_impl member:

--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -258,7 +258,7 @@ class UniquePointerPrinter:
         tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
         head_field = tuple_head_type.fields()[0]
         if head_field.name == '_M_head_impl':
-            self.pointer = tuple_member['_M_head_impl']
+            self.pointer = tuple_member.cast(tuple_head_type)['_M_head_impl']
         elif head_field.is_base_class:
             self.pointer = tuple_member.cast(head_field.type)
         else:

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |11.2.1, 12.0
   Target Milestone|---                         |11.3
      Known to work|                            |10.3.0
   Last reconfirmed|                            |2021-11-04
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This affects the filesystem::path printer too:

      impl = self.val['_M_cmpts']['_M_impl']['_M_t']['_M_t']['_M_head_impl']

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:a634928f5c8a281442ac8f5fb1636aed048ed72c

commit r12-4928-ga634928f5c8a281442ac8f5fb1636aed048ed72c
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Nov 4 22:50:02 2021 +0000

    libstdc++: Fix pretty printing of std::unique_ptr [PR103086]

    Since std::tuple started using [[no_unique_address]] the tuple<T*, D>
    member of std::unique_ptr<T, D> has two _M_head_impl subobjects, in
    different base classes. That means this printer code is ambiguous:

        tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
        head_field = tuple_head_type.fields()[0]
        if head_field.name == '_M_head_impl':
            self.pointer = tuple_member['_M_head_impl']

    In older versions of GDB it happened to work by chance, because GDB
    returned the last _M_head_impl member and std::tuple's base classes are
    stored in reverse order, so the last one was the T* element of the
    tuple. Since GDB 11 it returns the first _M_head_impl, which is the
    deleter element.

    The fix is for the printer to stop using an ambiguous field name and
    cast the tuple to the correct base class before accessing the
    _M_head_impl member.

    Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a
    new unique_ptr_get function is defined to do it correctly. That is
    defined in terms of new tuple_get and _tuple_impl_get functions.

    It would be possible to reuse _tuple_impl_get to access each element in
    StdTuplePrinter._iterator.__next__, but that already does the correct
    casting, and wouldn't be much simpler anyway.

    libstdc++-v3/ChangeLog:

            PR libstdc++/103086
            * python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper
            for accessing the tuple element stored in a _Tuple_impl node.
            (tuple_get): New function for accessing a tuple element.
            (unique_ptr_get): New function for accessing a unique_ptr.
            (UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get.
            * python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast
            tuple to its base class before accessing _M_head_impl.

[Bug libstdc++/103086] [11/12 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk so far.

The fix needs to be backported to gcc-11 because std::tuple uses
[[no_unique_address]] there, so the bug is present.

I think it's also present on older branches, but would only show up for a
unique_ptr with a non-empty pointer and non-empty deleter. I don't think we
test that, but I will check if it fails with GDB 11 and backport the fix if
needed.

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The branches all get this testcase wrong:

#include <memory>
#include "../util/testsuite_allocator.h"

struct Deleter
{
  int deleter_member = -1;
  using pointer = __gnu_test::NullablePointer<int*>;
  void operator()(pointer) const noexcept { }
};

int main()
{
  std::unique_ptr<int, Deleter> p;
  return 0;
}

I'll add that test, as well as backporting the fix from trunk.

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:fa4a8f3faaa1172b103c6a148a7830e7e6375cc3

commit r11-9271-gfa4a8f3faaa1172b103c6a148a7830e7e6375cc3
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Nov 4 22:50:02 2021 +0000

    libstdc++: Fix pretty printing of std::unique_ptr [PR103086]

    Since std::tuple started using [[no_unique_address]] the tuple<T*, D>
    member of std::unique_ptr<T, D> has two _M_head_impl subobjects, in
    different base classes. That means this printer code is ambiguous:

        tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
        head_field = tuple_head_type.fields()[0]
        if head_field.name == '_M_head_impl':
            self.pointer = tuple_member['_M_head_impl']

    In older versions of GDB it happened to work by chance, because GDB
    returned the last _M_head_impl member and std::tuple's base classes are
    stored in reverse order, so the last one was the T* element of the
    tuple. Since GDB 11 it returns the first _M_head_impl, which is the
    deleter element.

    The fix is for the printer to stop using an ambiguous field name and
    cast the tuple to the correct base class before accessing the
    _M_head_impl member.

    Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a
    new unique_ptr_get function is defined to do it correctly. That is
    defined in terms of new tuple_get and _tuple_impl_get functions.

    It would be possible to reuse _tuple_impl_get to access each element in
    StdTuplePrinter._iterator.__next__, but that already does the correct
    casting, and wouldn't be much simpler anyway.

    libstdc++-v3/ChangeLog:

            PR libstdc++/103086
            * python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper
            for accessing the tuple element stored in a _Tuple_impl node.
            (tuple_get): New function for accessing a tuple element.
            (unique_ptr_get): New function for accessing a unique_ptr.
            (UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get.
            * python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast
            tuple to its base class before accessing _M_head_impl.

    (cherry picked from commit a634928f5c8a281442ac8f5fb1636aed048ed72c)

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The regression caused by [[no_unique_address] and ambiguous field accesses is
fixed. I'll backport it to fix the latent bug on the other branches.

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:c59ec55c3459fba619e05ee7f59480b71e85ffd7

commit r12-5482-gc59ec55c3459fba619e05ee7f59480b71e85ffd7
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 23 21:35:40 2021 +0000

    libstdc++: Add another testcase for std::unique_ptr printer [PR103086]

    libstdc++-v3/ChangeLog:

            PR libstdc++/103086
            * testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr
            with non-empty pointer and non-empty deleter.

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:fa1ea255dba2d44ff22e434ed3d7778e8aaf4b91

commit r11-9275-gfa1ea255dba2d44ff22e434ed3d7778e8aaf4b91
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 23 21:35:40 2021 +0000

    libstdc++: Add another testcase for std::unique_ptr printer [PR103086]

    libstdc++-v3/ChangeLog:

            PR libstdc++/103086
            * testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr
            with non-empty pointer and non-empty deleter.

    (cherry picked from commit c59ec55c3459fba619e05ee7f59480b71e85ffd7)

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:5400112aa94163b1e94404e74b3000779d24303b

commit r10-10374-g5400112aa94163b1e94404e74b3000779d24303b
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Nov 4 22:50:02 2021 +0000

    libstdc++: Fix pretty printing of std::unique_ptr [PR103086]

    Since std::tuple started using [[no_unique_address]] the tuple<T*, D>
    member of std::unique_ptr<T, D> has two _M_head_impl subobjects, in
    different base classes. That means this printer code is ambiguous:

        tuple_head_type = tuple_impl_type.fields()[1].type   # _Head_base
        head_field = tuple_head_type.fields()[0]
        if head_field.name == '_M_head_impl':
            self.pointer = tuple_member['_M_head_impl']

    In older versions of GDB it happened to work by chance, because GDB
    returned the last _M_head_impl member and std::tuple's base classes are
    stored in reverse order, so the last one was the T* element of the
    tuple. Since GDB 11 it returns the first _M_head_impl, which is the
    deleter element.

    The fix is for the printer to stop using an ambiguous field name and
    cast the tuple to the correct base class before accessing the
    _M_head_impl member.

    Instead of fixing this in both UniquePointerPrinter and StdPathPrinter a
    new unique_ptr_get function is defined to do it correctly. That is
    defined in terms of new tuple_get and _tuple_impl_get functions.

    It would be possible to reuse _tuple_impl_get to access each element in
    StdTuplePrinter._iterator.__next__, but that already does the correct
    casting, and wouldn't be much simpler anyway.

    libstdc++-v3/ChangeLog:

            PR libstdc++/103086
            * python/libstdcxx/v6/printers.py (_tuple_impl_get): New helper
            for accessing the tuple element stored in a _Tuple_impl node.
            (tuple_get): New function for accessing a tuple element.
            (unique_ptr_get): New function for accessing a unique_ptr.
            (UniquePointerPrinter, StdPathPrinter): Use unique_ptr_get.
            * python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Cast
            tuple to its base class before accessing _M_head_impl.

    (cherry picked from commit a634928f5c8a281442ac8f5fb1636aed048ed72c)

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:865ad53c49953f2950901aaf45b34a38841df019

commit r10-10375-g865ad53c49953f2950901aaf45b34a38841df019
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Nov 23 21:35:40 2021 +0000

    libstdc++: Add another testcase for std::unique_ptr printer [PR103086]

    libstdc++-v3/ChangeLog:

            PR libstdc++/103086
            * testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr
            with non-empty pointer and non-empty deleter.

    (cherry picked from commit c59ec55c3459fba619e05ee7f59480b71e85ffd7)

[Bug libstdc++/103086] [11 Regression] std::unique_ptr printer gets confused by [[no_unique_address]] in tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103086

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Also fixed for 10.4 now.