[Bug libstdc++/40600] New: pair& operator=(pair&& __p) doesn't work without inlining

[rguenth at gcc dot gnu dot org]

25_algorithms/minmax/2.cc fails with -fno-inline because

  std::pair<const int&, const int&> z = std::minmax({1, 2, 3});

converts an rvalue to an lvalue:

  std::initializer_list<int>::initializer_list (&D.15746, &._65[0], 3);
  D.15878 = minmax<int> (D.15746);
  std::pair<const int&, const int&>::pair<int, int> (&z, &D.15878);

std::pair<_T1, _T2>::pair(std::pair<_U1, _U2>&&) [with _U1 = int, _U2 = int,
_T1 = const int&, _T2 = const int&] (struct pair * const this, struct pair &
__p)
{
  type D.16339;
  type & D.16338;
  int * D.16337;
  type D.16340;
  type D.16335;
  type & D.16334;
  int * D.16333;
  type D.16336;

<bb 2>:
  D.16333_2 = &__p_1(D)->first;
  D.16334_3 = move<int&> (D.16333_2);
  D.16335_4 = *D.16334_3;
  D.16336 = D.16335_4;
  this_5(D)->first = &D.16336;
  D.16337_6 = &__p_1(D)->second;
  D.16338_7 = move<int&> (D.16337_6);
  D.16339_8 = *D.16338_7;
  D.16340 = D.16339_8;
  this_5(D)->second = &D.16340;
  return;

effectively leaking an address to local stack (D.16336 and D.16340)
to the caller.

To me this looks like a general language defect.

I have a DCE patch that will expose this issue even when inlining is in effect.


-- 
           Summary: pair& operator=(pair&& __p) doesn't work without
                    inlining
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at gcc dot gnu dot org


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