[Bug c++/43785] New: very basic regression in std::make_pair

[Bug c++/43785] New: very basic regression in std::make_pair

[navin dot kumar at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

in GCC 4.4.2, the following compiles, but in GCC 4.5.0, it does not:
#include <iostream>
#include <math.h>

int main(int argc, char** argv)
{
    uint32_t x = 1;
    uint32_t y = 2;
    std::make_pair<uint32_t,uint32_t>(x, y);
    return 0;
}

In GCC4.5.0 the error is:
test.cpp: In function ‘int main(int, char**)’:
test.cpp:8:40: error: no matching function for call to ‘make_pair(uint32_t&,
uint32_t&)’


-- 
           Summary: very basic regression in std::make_pair
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: navin dot kumar at gmail dot com


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

[Bug c++/43785] very basic regression in std::make_pair

[navin dot kumar at gmail dot com]

------- Comment #1 from navin dot kumar at gmail dot com  2010-04-18 16:43 -------
Arguments: g++ -Wall -std=c++0x


-- 

navin dot kumar at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |navin dot kumar at gmail dot
                   |                            |com
      Known to fail|                            |4.5.0
      Known to work|                            |4.4.2


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

[Bug c++/43785] very basic regression in std::make_pair

[bangerth at gmail dot com]

------- Comment #2 from bangerth at gmail dot com  2010-04-18 19:02 -------
Confirmed. Including <utility> doesn't help.


-- 

bangerth at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at gmail dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-18 19:02:12
               date|                            |


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

[Bug c++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2010-04-19 01:06 -------
With C++0x we have:
  template<class _T1, class _T2>
    inline pair<typename __decay_and_strip<_T1>::__type,
  typename __decay_and_strip<_T2>::__type>
    make_pair(_T1&& __x, _T2&& __y)

Which is correct that lvalues cannot be bound to rvalue reference variables.

So this is a libstdc++ bug if it is a bug at all.  See PR 40486 about the
change to C++ front-end and the changes done to the library part.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2010-04-19 02:06 -------
Andrew, the situation isn't *that* simple as you seem to believe, because
make_pair is *templatized*, thus in general it works perfectly well with
lvalues. For example, this works:

  std::make_pair/*<std::uint32_t,std::uint32_t>*/(x, y);

that is, the problem is with the *explicit* template arguments. As far as I can
see, this can be either invalid or a defect in the standard, because we are
implementing quite closely the letter of N3035. In general, the C++0x std::pair
is still in flux, and we should be very careful. And I disagree about
considering this a regression.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2010-04-19 02:08 -------
Of course by "standard" I meant the current working draft, the FCD. We are in
the realm of the still *highly* experimental C++0x mode.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[paolo dot carlini at oracle dot com]

------- Comment #6 from paolo dot carlini at oracle dot com  2010-04-19 02:13 -------
In any case, Andrew is right (if I understand correctly the gist of his
message), that a conforming implementation of the FCD can *only* fail to
compile the provided snippet *when* the types are explicitely provided like
that: we boil down to uint32_t&& which *cannot* bind to an lvalue.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|navin dot kumar at gmail dot|
                   |com                         |


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[bangerth at gmail dot com]

------- Comment #7 from bangerth at gmail dot com  2010-04-19 02:59 -------
I think the point Andrew wanted to make is that it's a regression
*from the user perspective*. I had a half dozen places in our code
that now no longer compile in c++0x mode. Apparently others do too.

If the standard is not finished yet, I would think it rather useful
if we could implement something that is at least backward compatible.
In my eyes, the fact that we reject working code from previous standards
is a defect in the current draft.

W.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[redi at gcc dot gnu dot org]

------- Comment #8 from redi at gcc dot gnu dot org  2010-04-19 09:35 -------
It works fine without -std=c++0x, so is only a regression in code using an
experimental compiler mode which implements an incomplet and incorrekt
standard.

This is not the right place to open defect reports against the draft


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[redi at gcc dot gnu dot org]

------- Comment #9 from redi at gcc dot gnu dot org  2010-04-19 10:03 -------
Also, make_pair's reason for existing is to deduce template arguments. If you
don't want argument deduction why use make_pair?


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[navin dot kumar at gmail dot com]

------- Comment #10 from navin dot kumar at gmail dot com  2010-04-19 14:53 -------
However, what would make_pair have deduced its T1 and T2 to be in this example?
 My impression was "make_pair(x,y)" would have deduced T1=uint32_t and
T2=uint32_t.  Therefore, "make_pair<uint32_t,uint32_t>(x,y)" should be
synonymous.

The part that is confusing is if I do a diff on bits/stl_pair.h between
GCC4.4.2 and GCC4.5.0, the constructor has not changed.  Yet it compiles with
-std=c++0x on GCC4.4.2 but errors with -std=c++0x on GCC4.5.0  (which is why I
opened it up as a bug report to c++ initially rather than libstdc++).


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[navin dot kumar at gmail dot com]

------- Comment #11 from navin dot kumar at gmail dot com  2010-04-19 14:54 -------
typo: "constructor has not changed" in the above post should be "function has
not changed"


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[bangerth at gmail dot com]

------- Comment #12 from bangerth at gmail dot com  2010-04-19 14:57 -------
(In reply to comment #9)
> Also, make_pair's reason for existing is to deduce template arguments. If you
> don't want argument deduction why use make_pair?

True. I don't know why one would want to do this either, but several people
happened to do so about half a dozen times in our 500,000 lines of code.

W.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[redi at gcc dot gnu dot org]

------- Comment #13 from redi at gcc dot gnu dot org  2010-04-19 15:26 -------
(In reply to comment #10)
> However, what would make_pair have deduced its T1 and T2 to be in this example?
>  My impression was "make_pair(x,y)" would have deduced T1=uint32_t and
> T2=uint32_t.  Therefore, "make_pair<uint32_t,uint32_t>(x,y)" should be
> synonymous.

No, it would have deduced them as uint32_t& so make_pair<uint32_t&,uint32_t&>
is synonymous.  Otherwise it tries to bind uint32_t&& to an lvalue, which is
not allowed.


> The part that is confusing is if I do a diff on bits/stl_pair.h between
> GCC4.4.2 and GCC4.5.0, the constructor has not changed.  Yet it compiles with
> -std=c++0x on GCC4.4.2 but errors with -std=c++0x on GCC4.5.0  (which is why I
> opened it up as a bug report to c++ initially rather than libstdc++).

GCC 4.4 does not implement the updated rvalue reference semantics that prevent
lvalues binding to rvalues.


(In reply to comment #12)
> (In reply to comment #9)
> > Also, make_pair's reason for existing is to deduce template arguments. If you
> > don't want argument deduction why use make_pair?
> 
> True. I don't know why one would want to do this either, but several people
> happened to do so about half a dozen times in our 500,000 lines of code.

Well it's about time someone put a stop to it ;-)


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[redi at gcc dot gnu dot org]

------- Comment #14 from redi at gcc dot gnu dot org  2010-04-19 15:37 -------
(In reply to comment #13)
> Well it's about time someone put a stop to it ;-)

Seriously though, it's quicker to write e.g.
  return std::pair<uint32_t, uint32_t>(x, y) 
than
  return std::make_pair<uint32_t, uint32_t>(x, y);

I can't see why anyone would use the latter if they know both the arguments in
advance.  There is a valid use case for make_pair<uint32_t>(x, y), which
suppresses deduction for the first argument but not the second.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[bangerth at gmail dot com]

------- Comment #15 from bangerth at gmail dot com  2010-04-19 15:51 -------
(In reply to comment #14)
> > Well it's about time someone put a stop to it ;-)
> 
> Seriously though, it's quicker to write e.g.
>   return std::pair<uint32_t, uint32_t>(x, y) 
> than
>   return std::make_pair<uint32_t, uint32_t>(x, y);

No question. The point I wanted to make is that such code exists out there.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[redi at gcc dot gnu dot org]

------- Comment #16 from redi at gcc dot gnu dot org  2010-04-19 16:13 -------
Understood, but I don't see any way to fix that code.  std::make_pair has been
changed to handle rvalues, including deducing whether its arguments are lvalues
or rvalues.

By suppressing the type deduction you also suppress the lvalue/rvalue
deduction, so you had better get the types right, or you will try to bind an
rvalue to an lvalue.

It might be possible to provide an overload of make_pair which intentionally
can't deduce types and which only supports lvalues (like the old
std::make_pair) so that it will be chosen when the template args are given
explicitly:

template<class _T1, class _T2>
  inline pair<typename __decay_and_strip<_T1>::__type,
              typename __decay_and_strip<_T2>::__type>
  make_pair(const typename identity<_T1>::type& __x,
            const typename identity<_T2>::type&& __y)
  {
    return pair<typename __decay_and_strip<_T1>::__type,
              typename __decay_and_strip<_T2>::__type>(__x, __y);
  }

But it has taken so long to get pair to work correctly with rvalues that I
would be very cautious about changing anything now.  That overload could
introduce ambiguities I haven't considered.

My personal feeling is that it's better to break code misusing make_pair in
order to add rvalue support.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[redi at gcc dot gnu dot org]

------- Comment #17 from redi at gcc dot gnu dot org  2010-04-19 16:15 -------
(In reply to comment #16)
> 
> template<class _T1, class _T2>
>   inline pair<typename __decay_and_strip<_T1>::__type,
>               typename __decay_and_strip<_T2>::__type>
>   make_pair(const typename identity<_T1>::type& __x,
>             const typename identity<_T2>::type&& __y)
                                                ^^
                                                should be a single &


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[paolo dot carlini at oracle dot com]

------- Comment #18 from paolo dot carlini at oracle dot com  2010-04-20 02:23 -------
I largely agree with Jon. Note, at this stage in the standardization process
it's pretty difficult to change the working draft. Agreed, std::pair will be
different wrt the FCD, but if somebody want to change the current specs for
std::make_pair a National Body comment must be filed about that, as part of the
FCD ballot, which ends in May. The time is tight. FWIW, personally, I don't
consider this different behavior vs C++98 a Defect and Oracle has submitted
already all its comments.

As regards this PR, should be at minimum suspended pending the resolution of a
discussion within the LWG, or closed entirely as invalid if no National Body
comment is filed.


-- 


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

[Bug libstdc++/43785] [C++0x] std::make_pair vs explicit template arguments

[paolo dot carlini at oracle dot com]

------- Comment #19 from paolo dot carlini at oracle dot com  2010-04-28 09:14 -------
Closing as invalid, then.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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

[Bug libstdc++/43785] [C++0x] std::make_pair vs explicit template arguments

[pinskia at gcc dot gnu dot org]

------- Comment #20 from pinskia at gcc dot gnu dot org  2010-09-04 19:41 -------
*** Bug 45537 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at agmk dot net


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