[Bug libstdc++/55713] New: std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[Bug libstdc++/55713] New: std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[schaub.johannes at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713

             Bug #: 55713
           Summary: std::tuple<ElementType> incorrectly is convertible to
                    "ElementType" when it is an empty class
    Classification: Unclassified
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: schaub.johannes@googlemail.com


This code cannot be compiled with libstdc++

struct A {};
void f(A);

struct B { B(std::tuple<A>); };
void f(B);

int main() {
  f(std::make_tuple(A()));
}

GCC shouts

  "error: 'A' is an inaccessible base of 'tuple<A>'"

Libstdc++ should not make "std::tuple<EmptyClass>" derive from the empty class
directly.

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-16 17:49:20 UTC ---
This was done for an optimization. And I think it is allowed by the C++
standard too.

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[schaub.johannes at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713

--- Comment #2 from Johannes Schaub <schaub.johannes at googlemail dot com> 2012-12-16 17:52:14 UTC ---
(In reply to comment #1)
> This was done for an optimization. And I think it is allowed by the C++
> standard too.

>From the feedback I received from Stackoverflow (
http://stackoverflow.com/q/13902910/34509 ) I assumed that this behavior is not
permissible. There also appear to be ways to make it not behave that way (see
LLVM libc++'s implementation).

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-12-16
     Ever Confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-12-16 20:39:51 UTC ---
What stackoverflow says is not gospel, but I agree this should compile.

The summary is misleading, it's not convertible, because the base class is
inaccessible.

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> 2012-12-16 22:47:34 UTC ---
libc++'s implementation has the drawback that a tuple of empty types is not
empty (at least with the current ABI).

It seems a shame that sfinae now manages to handle access control cleverly
enough to disable overloads but regular code still handles access control as
something that is only checked after the fact.

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2012-12-16 00:00:00         |2020-3-19
   Target Milestone|---                         |11.0

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 49025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49025&action=edit
Replace inheritance with data member using [[no_unique_address]]

This fixes this bug and all the "See Also" ones, but there's an ICE for the
testcases from PR 94062. That ICE is tracked by PR 93711. Once that's fixed
I'll fix all these tuple issues.

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[cvs-commit at gcc dot gnu.org]

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

--- 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:91e6226f880b048275a7ceedef716e159c7cefd9

commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Aug 7 17:13:56 2020 +0100

    libstdc++: Remove inheritance from elements in std::tuple

    This fixes a number of std::tuple bugs by no longer making use of the
    empty base-class optimization. By using the C++20 [[no_unique_address]]
    attribute we can always store the element as a data member, while still
    compressing the layout of tuples containing empty types.

    Since we no longer use inheritance we could also apply the compression
    optimization for final types and for tuples of tuples, but doing so
    would be an ABI break.

    Using [[no_unique_address]] more liberally for the unstable std::__8
    configuration is left for a later date. There may be reasons not to
    apply the attribute unconditionally, e.g. see the discussion about
    guaranteed elision in PR 94062.

    libstdc++-v3/ChangeLog:

            PR libstdc++/55713
            PR libstdc++/71096
            PR libstdc++/93147
            * include/std/tuple [__has_cpp_attribute(no_unique_address)]
            (_Head_base<Idx, Head, true>): New definition of the partial
            specialization, using [[no_unique_address]] instead of
            inheritance.
            * testsuite/libstdc++-prettyprinters/48362.cc: Adjust expected
            output.
            * testsuite/20_util/tuple/comparison_operators/93147.cc: New test.
            * testsuite/20_util/tuple/creation_functions/55713.cc: New test.
            * testsuite/20_util/tuple/element_access/71096.cc: New test.

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[redi at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for GCC 11.

[Bug libstdc++/55713] std::tuple<ElementType> incorrectly is convertible to "ElementType" when it is an empty class

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
Bug 55713 depends on bug 93711, which changed state.

Bug 93711 Summary: [9 Regression] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711

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