[Bug libstdc++/59768] New: [4.8 Regression] std::thread constructor not handling reference_wrapper correctly

[Bug libstdc++/59768] New: [4.8 Regression] std::thread constructor not handling reference_wrapper correctly

[Casey at Carter dot net]

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

            Bug ID: 59768
           Summary: [4.8 Regression] std::thread constructor not handling
                    reference_wrapper correctly
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Casey at Carter dot net

Created attachment 31809
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31809&action=edit
Minimal test case.

Originally reported in Stackoverflow question
http://stackoverflow.com/questions/21059115/c11-thread-class-how-to-use-a-class-member-function

Construction of a std::thread with a pointer-to-member-function and
reference_wrapper as in this simple program:

#include <functional>
#include <iostream>
#include <thread>

class A {
public:
    void foo(int n) { std::cout << n << std::endl; }
};

int main()
{
    A a;

    std::thread t1(&A::foo, std::ref(a), 100);
    t1.join();
}

incorrectly results in a compilation error:

In file included from /usr/local/include/c++/4.8.2/thread:39:0,
                  from check.cc:2:
/usr/local/include/c++/4.8.2/functional: In instantiation of ‘struct
std::_Bind_simple<std::_Mem_fn<void (A::*)(int)>(std::reference_wrapper<A>,
int)>’:
/usr/local/include/c++/4.8.2/thread:137:47:   required from
‘std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = void
(A::*)(int); _Args = {std::reference_wrapper<A>, int}]’
check.cc:13:42:   required from here
/usr/local/include/c++/4.8.2/functional:1697:61: error：no type named ‘type’ in
‘class std::result_of<std::_Mem_fn<void (A::*)(int)>(std::reference_wrapper<A>,
int)>’
        typedef typename result_of<_Callable(_Args...)>::type result_type;
                                                              ^
/usr/local/include/c++/4.8.2/functional:1727:9: error：no type named ‘type’ in
‘class std::result_of<std::_Mem_fn<void (A::*)(int)>(std::reference_wrapper<A>,
int)>’
          _M_invoke(_Index_tuple<_Indices...>)
          ^

I reduced the original program to:

#include <functional>
#include <thread>

int main() {
  struct A { void foo(int) {} } a;
  std::thread(&A::foo, std::ref(a), 100).join();
}

which still displays the erroneous behavior. Note that std::bind(&A::foo,
std::ref(a), 100) *does* compile correctly, as does a similar program in which
the member function foo has no parameter.

Program is incorrectly compiled by g++ 4.8.2 and 4.8.1, correctly compiles with
4.6.4 and 4.7.3.
>From gcc-bugs-return-440073-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 11 08:14:47 2014
Return-Path: <gcc-bugs-return-440073-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8928 invoked by alias); 11 Jan 2014 08:14:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8868 invoked by uid 48); 11 Jan 2014 08:14:41 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
Date: Sat, 11 Jan 2014 08:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-28865-4-zc1Y3vUm39@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-28865-4@http.gcc.gnu.org/bugzilla/>
References: <bug-28865-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01215.txt.bz2
Content-length: 832

http://gcc.gnu.org/bugzilla/show_bug.cgi?id(865

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I disagree.  DECL_SIZE and .size are IMHO correct here at this point, and
component sizes (FIELD_DECL) can't match, because we shouldn't be changing the
type of the decl to some other type just because it got an initializer.  The
bug is IMHO really just in miscounting the size of the padding of the
initializer and thus emitting into the data/rodata etc. section more bytes of
data from what .size/arrays/-fsection-anchors assumes.  Outside of arrays on
non-fsection-anchors target this is just ugly (except where you e.g. put the
structs into named sections and use it as a kind of array say through
beginning/end of the named section), for -fsection-anchors it is of course a
wrong-code (well, wrong-data) bug.

[Bug libstdc++/59768] [4.8 Regression] std::thread constructor not handling reference_wrapper correctly

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-01-11
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug libstdc++/59768] [4.8 Regression] std::thread constructor not handling reference_wrapper correctly

[Casey at Carter dot net]

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

--- Comment #1 from Casey Carter <Casey at Carter dot net> ---
This behavior would appear to NOT be erroneous. I was operating under the
assumption that the behavior of the std::thread constructor and std::bind were
identical by design given that both use the "INVOKE" machinery defined by the
standard in [func.require]/1. However, the replacement of reference_wrapper<A>
with its stored reference is specified only for std::bind in
[func.bind.bind]/10:


The values of the bound arguments v1, v2, ..., vN and their corresponding types
V1, V2, ..., VN depend on the types TiD derived from the call to bind and the
cv-qualifiers cv of the call wrapper g as follows:

— if TiD is reference_wrapper<T>, the argument is tid.get() and its type Vi is
T&;


This would then not be a regression in the 4.8 line, but a correction to a
long-standing bug. I apologize for wasting your time with an erroneous bug
report.
>From gcc-bugs-return-440093-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 11 16:40:38 2014
Return-Path: <gcc-bugs-return-440093-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19667 invoked by alias); 11 Jan 2014 16:40:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19615 invoked by uid 48); 11 Jan 2014 16:40:33 -0000
From: "doko at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/59770] New: [4.9 Regression] bootstrap failure for arm-linux-gnueabi targeting armv4t
Date: Sat, 11 Jan 2014 16:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: doko at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-59770-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01235.txt.bz2
Content-length: 2371

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY770

            Bug ID: 59770
           Summary: [4.9 Regression] bootstrap failure for
                    arm-linux-gnueabi targeting armv4t
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org

trunk 20140111, arm-linux-gnueabi targeting armv4t ftbfs, arm-linux-gnueabihf
targeting armv7 succeeds to build.

configure -v --with-pkgversion='Debian 4.9-20140111-1'
--with-bugurl='file:///usr/share/doc/gcc-4.9/README.Bugs'
--enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armel/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armel
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armel
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv4t --with-float=soft --enable-checking=release
--build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi

make[5]: Entering directory
`/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build/gcc'
build/genpreds -c ../../src/gcc/config/arm/arm.md > tmp-constrs.h
/bin/bash: line 1: 31819 Segmentation fault      build/genpreds -c
../../src/gcc/config/arm/arm.md > tmp-constrs.h
make[5]: *** [s-constrs-h] Error 139
make[5]: Leaving directory
`/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build/gcc'
make[4]: *** [all-stage3-gcc] Error 2
make[4]: Leaving directory
`/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build'
make[3]: *** [stage3-bubble] Error 2
make[3]: Leaving directory
`/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build'
make[2]: *** [bootstrap] Error 2

[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED
            Summary|[4.8 Regression]            |[DR 2219] std::thread
                   |std::thread constructor not |constructor not handling
                   |handling reference_wrapper  |reference_wrapper correctly
                   |correctly                   |

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, I introduced __bind_simple specifically to provide the functionality
needed by std::thread (and other components) because it's not the same as
std::bind, which we were using previously.

I've actually reported a defect against the standard saying this *should* work
(but currently it's not allowed to), see
http://cplusplus.github.io/LWG/lwg-active.html#2219