[Bug libstdc++/54259] New: Regression in move construction for std::pair

[Bug libstdc++/54259] New: Regression in move construction for std::pair

[oleg at smolsky dot net]

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

             Bug #: 54259
           Summary: Regression in move construction for std::pair
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: oleg@smolsky.net


I've just attempted to move my project from g++ v4.6.3 to v4.7.1 and hit an
issue when using move semantics.

I have a templated class LockGuard that is move-constructable and not copyable.
This is accomplished (in the conventional C++98 way) by making the copy
constructor "private". The code creates an instance of std::pair<...,
LockGuard<...>> and returns it to the caller.

The code compiles and runs on g++ 4.6.3 and VS2010/sp1, yet g++ 4.7.1 emits a
bunch of errors (below). The point, as far as I can tell, is that it wants to
call the copy constructor which is private. I can fix the issue by explicitly
removing the copy constructor:

    LockGuard(const LockGuard &) = delete;

Could someone clarify if this behavior is conforming to the standard? Normally
I would not worry about such a thing, but VS2010 does not understand "= delete"
specs and the behavior appears to be a breaking change w.r.t. copy constructor
invocations... (well, breaking is too strong a word as move constructors and
rvalue references are new, but I am sure you see what I mean)

[Bug libstdc++/54259] Regression in move construction for std::pair

[oleg at smolsky dot net]

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

--- Comment #1 from oleg at smolsky dot net 2012-08-14 16:27:35 UTC ---
Created attachment 28015
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28015
minimal expressive test case

Compiles correctly in g++ 4.6.3, 4.8/Trunk and VS2010/sp1.

[Bug libstdc++/54259] Regression in move construction for std::pair

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|debian on amd64             |
               Host|debian on amd64             |

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-08-14 16:51:56 UTC ---
It looks like a problem caused by 4.7 not implementing access control for
SFINAE, which is fixed on trunk. 

You can workaround it by removing your private copy constructor and inheriting
from a type like boost::noncopyable:

    struct noncopyable
    {
        noncopyable() { }
    private:
        noncopyable(const noncopyable&);
    };


    template <class Type>
    class LockGuard : noncopyable
    {
      // ...
    private:
      // LockGuard(const LockGuard &);
    };

Now LockGuard's copy constructor will be deleted, and works well with SFINAE.

[Bug libstdc++/54259] Regression in move construction for std::pair

[oleg at smolsky dot net]

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

--- Comment #3 from oleg at smolsky dot net 2012-08-14 21:09:03 UTC ---
Thank you Jonathan. The workaround works on all three compilers and I can move
forward.

[Bug c++/54259] [4.7 Regression] Regression in move construction for std::pair

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
          Component|libstdc++                   |c++
      Known to work|                            |4.8.0
   Target Milestone|---                         |4.7.2
            Summary|Regression in move          |[4.7 Regression] Regression
                   |construction for std::pair  |in move construction for
                   |                            |std::pair

[Bug c++/54259] [4.7 Regression] Regression in move construction for std::pair

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-08-15 14:46:11 UTC ---
Re component -> c++

Although the error is due to a limitation in the FE, it's not a regression in
the FE, as SFINAE has never respected access control until very recently on
trunk.

The regression is caused by a change to libstdc++ which uses
std::is_convertible in std::pair now, and that gives an error if overload
resolution chooses a private constructor.

[Bug c++/54259] [4.7 Regression] Regression in move construction for std::pair

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.2                       |4.7.3

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-20 10:18:50 UTC ---
GCC 4.7.2 has been released.

[Bug c++/54259] [4.7 Regression] Regression in move construction for std::pair

[rguenth at gcc dot gnu.org]

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

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

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

[Bug c++/54259] [4.7 Regression] Regression in move construction for std::pair

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-12-05 13:18:34 UTC ---
Let's close this, we are not going to backport access control for SFINAE in the
branch and there are decent workarounds.