[Bug c++/109405] New: Should class final decoration result in larger unique_ptr with deleter ?

[Bug c++/109405] New: Should class final decoration result in larger unique_ptr with deleter ?

[gcc at hazlewoods dot net]

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

            Bug ID: 109405
           Summary: Should class final decoration result in larger
                    unique_ptr with deleter ?
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at hazlewoods dot net
  Target Milestone: ---

Whilst making an attempt to ensure some `std::unique_ptr<>` types had size
`sizeof(intptr_t)`, I was using empty `struct` deleters.
I habitually tapped `final` on a struct, and was surprised to see my
`static_assert`s fire.

Maybe this is a consequence of the push for devirtualization optimization, but
hopefully this can be confirmed.

```
#include <iostream>
#include <memory>

int main()
{
    struct S { void operator()() {} };
    struct SF final { void operator()() {} };
    std::cout << "S : " << sizeof(S) << std::endl;
    std::cout << "SF: " << sizeof(SF) << std::endl;

    using SP = std::unique_ptr<int, S>;
    using SFP = std::unique_ptr<int, SF>;
    std::cout << "SP : " << sizeof(SP) << std::endl;
    std::cout << "SFP: " << sizeof(SFP) << std::endl;
}
```


https://godbolt.org/z/Gfz4W5sP1

[Bug c++/109405] Should class final decoration result in larger unique_ptr with deleter ?

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is expected. The unique_ptr implementation uses tuple<int*, SF> which is
similarly dependent on whether the tuple elements are final or not. Originally,
that was because we used inheritance in tuple, in order to take advantage of
the empty-base class optimization. Obviously we can't use inheritance for final
types.

These days we do not use inheritance, we use the [[no_unique_address]]
attribute so that empty tuple elements take no space. But to avoid an ABI
incompatibility with previous versions of GCC, the attribute is only used for
non-final types.

There's no way to fix this without breaking the library's ABI.

[Bug c++/109405] Should class final decoration result in larger unique_ptr with deleter ?

[gcc at hazlewoods dot net]

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

--- Comment #2 from Richard Hazlewood <gcc at hazlewoods dot net> ---
Ah, ok.  Thanks for quick response.

[Bug libstdc++/109405] Should class final decoration result in larger unique_ptr with deleter ?

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
                 CC|                            |xry111 at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
WONTFIX then.

[Bug libstdc++/109405] Should class final decoration result in larger unique_ptr with deleter ?

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's possible to fix for the --enable-symvers=gnu-versioned-namespace build
which does not promise a backwards compatible ABI. I didn't do that yet, I
*think* it was because support for [[no_unique_address]] was still patchy in
Clang and other non-GCC compilers. Maybe that's no longer an issue and it could
be done now.