From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30243 invoked by alias); 11 Jan 2014 07:34:34 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30222 invoked by uid 48); 11 Jan 2014 07:34:29 -0000 From: "Casey at Carter dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/59768] New: [4.8 Regression] std::thread constructor not handling reference_wrapper correctly Date: Sat, 11 Jan 2014 07:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Casey at Carter dot net 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 attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg01214.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59768 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=3D31809&action=3Dedit Minimal test case. Originally reported in Stackoverflow question http://stackoverflow.com/questions/21059115/c11-thread-class-how-to-use-a-c= lass-member-function Construction of a std::thread with a pointer-to-member-function and reference_wrapper as in this simple program: #include #include #include 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 =E2=80=98struct std::_Bind_simple(std::reference_wrapper, int)>=E2=80=99: /usr/local/include/c++/4.8.2/thread:137:47: required from =E2=80=98std::thread::thread(_Callable&&, _Args&& ...) [with _Callable =3D = void (A::*)(int); _Args =3D {std::reference_wrapper, int}]=E2=80=99 check.cc:13:42: required from here /usr/local/include/c++/4.8.2/functional:1697:61: error=EF=BC=9Ano type name= d =E2=80=98type=E2=80=99 in =E2=80=98class std::result_of(std::reference= _wrapper, int)>=E2=80=99 typedef typename result_of<_Callable(_Args...)>::type result_type; ^ /usr/local/include/c++/4.8.2/functional:1727:9: error=EF=BC=9Ano type named= =E2=80=98type=E2=80=99 in =E2=80=98class std::result_of(std::reference= _wrapper, int)>=E2=80=99 _M_invoke(_Index_tuple<_Indices...>) ^ I reduced the original program to: #include #include 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 wh= ich 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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=28865 --- Comment #18 from Jakub Jelinek --- 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.