[Bug c++/58824] New: Lambda trigger internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58824
Bug ID: 58824
Summary: Lambda trigger internal compiler error
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.sanchz at gmail dot com
Created attachment 31058
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31058&action=edit
Source file + ii + s
Hi,
Please see in attached file the source triggering an internal error in gcc.
The source file is compiled like this:
$> g++ -std=c++11 -W -Wall -Wextra test.cpp
test.cpp: In instantiation of ‘struct test::__lambda0’:
test.cpp:5:8: required from here
test.cpp:8:20: internal compiler error: in tsubst_copy, at cp/pt.c:12116
{ "test", [this]{} }
The bug is triggered when `this` is captured from a template class and the
lambda is assigned directly from the class definition.
The platform tested is an ubuntu 13.10 with default shipped compiler:
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --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.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8)
The bug is still present in gcc4.9 (tested via: http://gcc.godbolt.org/).
I joined the *i files even if I doubt that they'll be helpful in this
particular bug.
[Bug c++/58824] Lambda trigger internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58824 Thomas Sanchez changed: What|Removed |Added Attachment #31058|0 |1 is obsolete|| --- Comment #1 from Thomas Sanchez --- Created attachment 31059 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31059&action=edit Only source file Sorry for the archive...
[Bug c++/58824] Lambda trigger internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58824 --- Comment #3 from Thomas Sanchez --- The code is 21 lines... I can't reproduce the bug otherwise...
[Bug c++/58824] Lambda trigger internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58824 Thomas Sanchez changed: What|Removed |Added Attachment #31059|0 |1 is obsolete|| CC||thomas.sanchz at gmail dot com --- Comment #6 from Thomas Sanchez --- Created attachment 31060 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31060&action=edit Source file Source file without any include added.
[Bug c++/58824] Lambda trigger internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58824 --- Comment #8 from Thomas Sanchez --- You're welcome, good luck !
[Bug c++/59435] New: sizeof...(T) as default value for an argument does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59435
Bug ID: 59435
Summary: sizeof...(T) as default value for an argument does not
work
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.sanchz at gmail dot com
Hi everybody,
I encountered something not supported in gcc from 4.7 to 4.9, but working in
clang from 3.2 (tested on gcc goldbot).
Here is the code:
template
struct T
{
T(unsigned int i = sizeof...(E)){} // does not compile
static constexpr unsigned int U = sizeof...(E);
T(unsigned int j, unsigned int i = U){} // compile
};
template
void test(int i = sizeof...(T)) // compile
{}
Invocation with "g++ -std=c++11 test.cpp" is enough to reproduce the bug.
Please let me know if you need more information.
Cheers,
[Bug c++/80679] New: call of overloaded is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80679
Bug ID: 80679
Summary: call of overloaded is ambiguous
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.sanchz at gmail dot com
Target Milestone: ---
Hi,
First reported there https://github.com/mapbox/jni.hpp/pull/17
The following code is compiling fine on clang but fails on g++
template
class Method {};
template
void Call(const Method&, const Args&... args) {}
template
void Call(const Method&, const Args&... args) {}
int main() {
Call(Method(), int());
}
Cheers,
[Bug libstdc++/60966] New: std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
Bug ID: 60966
Summary: std::call_once sometime hangs
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.sanchz at gmail dot com
Hi,
I'm really sorry for the vague bug report and not being able to give a small
piece of code to reproduce the bug.
Here is what I'm experiencing:
I developed a small library which performs http request, the library is built
around curl.
I'm using std::promise/future in order to push a task to do in the thread were
all the operation on the handle is done.
for example, here is an example of some of the piece of the code I have:
{
std::promise promise;
auto future = promise.get_future();
io.dispatch([this, &promise]
{
checkHandles();
promise.set_value();
});
future.get();
}
Sometimes, it can hangs on the set_value() with this kind of stack trace:
(gdb) bt
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x774f766c in
std::condition_variable::wait(std::unique_lock&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00647555 in
std::condition_variable::wait(std::unique_lock&,
std::__future_base::_State_base::wait()::{lambda()#1}) (this=0xa28990,
__lock=..., __p=...) at /usr/include/c++/4.8/condition_variable:93
#3 0x00643d1c in std::__future_base::_State_base::wait (this=0xa28958)
at /usr/include/c++/4.8/future:327
#4 0x006b29bf in std::__basic_future::_M_get_result
(this=0x7fffa150) at /usr/include/c++/4.8/future:595
#5 0x006b1626 in std::future::get (this=0x7fffa150) at
/usr/include/c++/4.8/future:760
#6 0x006acb21 in HTTPP::HTTP::client::detail::Manager::~Manager
(this=0x9efe90, __in_chrg=) at
/home/daedric/perso/httpp/src/httpp/http/client/Manager.cpp:113
#7 0x0069d92a in
std::default_delete::operator()
(this=0x9f1168, __ptr=0x9efe90) at /usr/include/c++/4.8/bits/unique_ptr.h:67
#8 0x0069d53c in std::unique_ptr >::reset
(this=0x9f1168, __p=0x9efe90) at /usr/include/c++/4.8/bits/unique_ptr.h:262
#9 0x0069b17f in HTTPP::HttpClient::~HttpClient (this=0x9f10c8,
__in_chrg=) at
/home/daedric/perso/httpp/src/httpp/HttpClient.cpp:48
#10 0x0065724e in etcd::Etcd::Connection::~Connection (this=0x9f10c0,
__in_chrg=) at /home/daedric/work/broker/broker/etcd/Etcd.cpp:28
#11 0x0065727e in
std::default_delete::operator() (this=0xa27780,
__ptr=0x9f10c0) at /usr/include/c++/4.8/bits/unique_ptr.h:67
#12 0x00655f1b in std::unique_ptr >::~unique_ptr (this=0xa27780,
__in_chrg=) at /usr/include/c++/4.8/bits/unique_ptr.h:184
#13 0x0065483e in std::_Destroy > > (__pointer=0xa27780) at
/usr/include/c++/4.8/bits/stl_construct.h:93
#14 0x0065295c in
std::_Destroy_aux::__destroy >*> (__first=0xa27780,
__last=0xa27788) at /usr/include/c++/4.8/bits/stl_construct.h:103
#15 0x0064fefb in std::_Destroy >*> (__first=0xa27780,
__last=0xa27788) at /usr/include/c++/4.8/bits/stl_construct.h:126
#16 0x0064c065 in std::_Destroy >*,
std::unique_ptr > > (__first=0xa27780,
__last=0xa27788) at /usr/include/c++/4.8/bits/stl_construct.h:151
#17 0x0064d4c8 in std::vector >,
std::allocator > > >::_M_erase_at_end
(this=0x7fffaf00, __pos=0xa27780)
at /usr/include/c++/4.8/bits/stl_vector.h:1352
#18 0x006489c0 in std::vector >,
std::allocator > > >::clear (this=0x7fffaf00)
at /usr/include/c++/4.8/bits/stl_vector.h:1126
#19 0x0063ccb0 in etcd::Etcd::~Etcd (this=0x7fffaea0,
__in_chrg=) at
/home/daedric/work/broker/broker/etcd/Etcd.cpp:264
#20 0x0063118c in basic::test_method (this=0x7fffd68f) at
/home/daedric/work/broker/tests/etcd/tree.cpp:70
#21 0x006300cf in basic_invoker () at
/home/daedric/work/broker/tests/etcd/tree.cpp:12
#22 0x0063bd64 in
boost::unit_test::ut_detail::invoker::invoke (this=0x7fffd6ef, f=@0x9e8048: 0x6300bb ) at
/usr/include/boost/test/utils/callback.hpp:56
#23 0x0063bbb4 in
boost::unit_test::ut_detail::callback0_impl_t::invoke (this=0x9e8040) at
/usr/include/boost/test/utils/callback.hpp:89
#24 0x006ded01 in boost::unit_test::ut_detail::callback0_impl_t
> >::invoke() ()
#25 0x006feeb6 in
boost::execution_monitor::catch_signals(boost::unit_test::callback0
const&) ()
#26 0x006ff6c3 in
boost::execution_monitor::execute(boost::unit_test::callback0 const&) ()
#27 0x006deddb in
boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case
const&) ()
#28 0x006cd8a4 in
boost::u
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #2 from Thomas Sanchez --- Hi, Thanks for your answer, (In reply to Jonathan Wakely from comment #1) > (It would be easier to make sense of this if the line numbers in your gdb > and valgrind output matched the code on github.) > Indeed, sorry, I added some debug that I did not commit, I'll create a branch with this version tomorrow. The important things is that it is always on set_value() that I hang. > Blocking in pthread_once could be a symptom of using an invalid > pthread_once_t that has already been destroyed, and the valgrind output > indeed shows that the set_value() call is being made on a shared state that > has been deleted already, when the promise that owned it went out of scope. > It looks like that shouldn't have happened though. > I reached the same conclusion. > Is it possible the task is getting run twice by the thread pool, so on the > second run the reference to the promise is dangling? Hum, since I'm using boost::asio (boost::asio::io_service::post/dispatch), I do hope that this is not the case, but this is something I can check. I don't remember however having a double log. > > When the process hangs could you use gdb to print &promise in both threads, > where it is waiting on future::get and promise::set_value? The values should > be the same, since the closure running in the thread pool should have a > reference to the local object in the waiting thread. Will do. > > Replacing the lambda in the destructor with a call to a member function > would help to rule out a code generation problem due to the lambda, which is > a remote possibility. > Will do. > Can the problem be reproduced by one of the unit tests in the httpp repo? > Unfortunately I don't have anything to reproduce the bug each time. I'll try something tomorrow. > > N.B. the std::move in Manager::cancelConnection is redundant, the return > value from cancel_connection is already an rvalue. Yes, I know, the problem is I have some hard time to avoid doing this as it is more for me and what I expect the compiler to do or the semantics I want the code to have :)
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #4 from Thomas Sanchez ---
(In reply to Jonathan Wakely from comment #3)
> > > N.B. the std::move in Manager::cancelConnection is redundant, the return
> > > value from cancel_connection is already an rvalue.
> >
> > Yes, I know, the problem is I have some hard time to avoid doing this as it
> > is more for me and what I expect the compiler to do or the semantics I want
> > the code to have :)
>
> OK, but it makes the code worse. Here the compiler will elide the move
> constructor (aka return value optimisation):
>
> auto future = cancel_connection(c);
>
> Whereas here the compiler cannot do that and must call a move constructor:
>
> auto future = std::move(cancel_connection(c));
I did not meant to say I should continue, far from here :) Thank for the
notice!
Anyway, I pushed the actual code in this branch:
https://github.com/daedric/httpp/tree/bug-promise-test
I was able to do a small test that can *sometimes* reproduce the bug:
https://github.com/daedric/httpp/blob/bug-promise-test/tests/client/promise.cpp
Since I was able to trigger the problem, here are what you asked for:
>From the get side, (from here
https://github.com/daedric/httpp/blob/bug-promise-test/src/httpp/http/client/Manager.cpp#L113)
(gdb) print future
$1 = {
> = {
= {},
members of std::__basic_future:
_M_state = std::shared_ptr (count 2, weak 0) 0x805468
}, }
(gdb) print promise
$2 = {
_M_future = std::shared_ptr (count 2, weak 0) 0x805468,
_M_storage = std::unique_ptr> containing
0x805780
}
(gdb) print &promise
$3 = (std::promise *) 0x7fffce90
>From the thread calling the pthread_once:
#4 0x00500d67 in std::promise::set_value (this=0x7fffce90)
at /usr/include/c++/4.8/future:1197
1197_M_future->_M_set_result(std::move(__setter));
(gdb) print *this
$4 = {
_M_future = std::shared_ptr (count 2, weak 0) 0x805468,
_M_storage = std::unique_ptr> containing
0x805780
}
This is seems to be correct.
This has been produced with commit: 850ebba9a72d102b54de6912e820889618a4f30d
I'm testing now with the lambdas replaced :)
http://reproducible.io/
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #5 from Thomas Sanchez ---
With my previous mail, the link I added was because I wanted to ask that if you
were not able to reproduce the problem I could use CARE to recreate the
environment I'm running my test.
With lambda replaced (commit fd8b4a8ce7847dc561c937e2a3c80db0d735835c) the
seems to be triggered a bit less often however, I do have a segfault in
malloc_consolidate, I'll come back onto this later.
Manager.cpp:121
(gdb) print future
$1 = {
> = {
= {},
members of std::__basic_future:
_M_state = std::shared_ptr (count 2, weak 0) 0x812468
}, }
(gdb) print promise
$2 = {
_M_future = std::shared_ptr (count 2, weak 0) 0x812468,
_M_storage = std::unique_ptr> containing
0x812780
}
Manager.cpp:87
(gdb) print promise
$3 = (std::promise &) @0x7fffce40: {
_M_future = std::shared_ptr (count 2, weak 0) 0x812468,
_M_storage = std::unique_ptr> containing
0x812780
}
This also seems ok.
About the segfault on the malloc, I think the problems are related, I guess it
is possible that the pthread_once does not always hangs and who knows what mess
it could cause in the memory.
In case you interested in the segfault, here is the trace:
Program received signal SIGSEGV, Segmentation fault.
malloc_consolidate (av=av@entry=0x7722c760 ) at malloc.c:4157
4157malloc.c: No such file or directory.
(gdb) bt
#0 malloc_consolidate (av=av@entry=0x7722c760 ) at
malloc.c:4157
#1 0x76eedc38 in _int_malloc (av=0x7722c760 ,
bytes=7288) at malloc.c:3423
#2 0x76ef05f0 in __GI___libc_malloc (bytes=7288) at malloc.c:2891
#3 0x77984d8f in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#4 0x77984ecf in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5 0x77985cbd in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6 0x00506a08 in HTTPP::HTTP::client::detail::Manager::Manager
(this=0x811eb0, io=..., dispatch=...) at
/home/daedric/perso/httpp/src/httpp/http/client/Manager.cpp:52
#7 0x004ef61b in HTTPP::HttpClient::HttpClient (this=0x7fffcfb0,
nb_thread=1, name="") at /home/daedric/perso/httpp/src/httpp/HttpClient.cpp:38
The segfault on the call of curl_multi_init and this one occurs in the
constructor. I was not able to check with valgrind so far if a failed
instanciation occurs after a trace about an invalid call_once/pthread_once
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #6 from Thomas Sanchez --- Last comment on myself: I got some errors relates to the promise with valgrind but they do not cause an hangs ==30999== Thread 2: ==30999== Invalid read of size 4 ==30999==at 0x4E44A91: pthread_once (pthread_once.S:111) ==30999==by 0x4F4274: __gthread_once(int*, void (*)()) (gthr-default.h:699) ==30999==by 0x4FADBC: void std::call_once ()>&, bool&), std::__future_base::_State_base* const, std::reference_wrapper ()> >, std::reference_wrapper >(std::once_flag&, void (std::__future_base::_State_base::*&&)(std::function ()>&, bool&), std::__future_base::_State_base* const&&, std::reference_wrapper ()> >&&, std::reference_wrapper&&) (mutex:786) ==30999==by 0x4F75A2: std::__future_base::_State_base::_M_set_result(std::function ()>, bool) (future:358) ==30999==by 0x50B666: std::promise::set_value() (future:1197) ==30999==by 0x506E1F: HTTPP::HTTP::client::detail::Manager::check_handles(std::promise&) (Manager.cpp:87) ==30999==by 0x51D9A6: void std::_Mem_fn&)>::operator()&, void>(HTTPP::HTTP::client::detail::Manager*, std::promise&) const (in /home/daedric/perso/httpp/build/tests/client/Test_Client_promise) ==30999==by 0x51CFBE: void std::_Bind&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)>::__call(std::tuple<>&&, std::_Index_tuple<0ul, 1ul>) (functional:1296) ==30999==by 0x51C4FF: void std::_Bind&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)>::operator()<, void>() (functional:1355) ==30999==by 0x51B594: void boost::asio::asio_handler_invoke&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)> >(std::_Bind&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)>, ...) (handler_invoke_hook.hpp:64) ==30999==by 0x519E81: void boost_asio_handler_invoke_helpers::invoke&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)>, std::_Bind&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)> >(std::_Bind&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)>&, std::_Bind&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)>&) (handler_invoke_helpers.hpp:37) ==30999==by 0x51B6CE: boost::asio::detail::completion_handler&)> (HTTPP::HTTP::client::detail::Manager*, std::reference_wrapper >)> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (completion_handler.hpp:68) ==30999== Address 0xdbd3b54 is 132 bytes inside a block of size 136 free'd ==30999==at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==30999==by 0x504C41: __gnu_cxx::new_allocator, (__gnu_cxx::_Lock_policy)2> >::deallocate(std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>*, unsigned long) (new_allocator.h:110) ==30999==by 0x5045F2: std::allocator_traits, (__gnu_cxx::_Lock_policy)2> > >::deallocate(std::allocator, (__gnu_cxx::_Lock_policy)2> >&, std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>*, unsigned long) (alloc_traits.h:377) ==30999==by 0x505D85: std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>::_M_destroy() (shared_ptr_base.h:417) ==30999==by 0x4F2A51: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:161) ==30999==by 0x4F1CC4: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:546) ==30999==by 0x4F15F3: std::__shared_ptr::~__shared_ptr() (shared_ptr_base.h:781) ==30999==by 0x4F160D: std::shared_ptr::~shared_ptr() (shared_ptr.h:93) ==30999==by 0x50B491: std::promise::~promise() (future:1136) ==30999==by 0x5071C3: HTTPP::HTTP::client::detail::Manager::~Manager() (Manager.cpp:121) ==30999==by 0x4F2F2B: std::default_delete::operator()(HTTPP::HTTP::client::detail::Manager*) const (unique_ptr.h:67) ==30999==by 0x4F262F: std::unique_ptr >::reset(HTTPP::HTTP::client::detail::Manager*) (unique_ptr.h:262)
[Bug libstdc++/60966] std::call_once sometime hangs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #8 from Thomas Sanchez --- Hey, I just wanted to know if you had the time to look into and/or if you were able to reproduce the bug ? Thanks,
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #12 from Thomas Sanchez --- Hi Hideaki, I was able to workaround the bug by using boost promise instead of the STL one. I did not have the time to investigate the bug however, I'm not really familiar with the STL design :( Here is what I needed to do: https://github.com/daedric/httpp/commit/b7d9a36c7a9fe9fdaed1771326c1c5e5eaaa507c I did not hit the problem again so far. Good luck ! Are you able to produce a smaller code which trigger the bug than I was?
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #26 from Thomas Sanchez --- In the end the problem is quite simple :) One workaround would be to move the promise into the lambda however I would be glad that your patch get accepted, because IMHO it is not an expected behavior from a user point of view ! Thanks a lot for your work !
[Bug libstdc++/63329] New: std::bind does not define argument_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63329
Bug ID: 63329
Summary: std::bind does not define argument_type
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.sanchz at gmail dot com
Hi,
It looks like the data structure returned by bind does not contain some type
(argument_type) required by std::not1 for instance.
It works with clang + the libc++ on Mac Os X.
#include
#include
struct Test { bool pred() const { return true; } };
int main(int argc, char *argv[])
{
// works
auto f1 = std::not1(std::mem_fn(&Test::pred));
// works
auto f2 = std::not1(std::mem_fun(&Test::pred));
// does not work: error: no type named ‘argument_type’
auto f3 = std::not1(std::bind(&Test::pred, std::placeholders::_1));
}
Thanks a lot.
[Bug libstdc++/63329] std::bind does not define argument_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63329 --- Comment #1 from Thomas Sanchez --- BTW, I forgot to add that the compiler is invoked with this command: g++ -std=c++11 test.cpp Also, funny thing, with clang, it is the first one that do not compile :) Thanks,
[Bug libstdc++/63329] std::bind does not define argument_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63329 --- Comment #3 from Thomas Sanchez --- While it is not really intuitive I understand. Thanks for your time!
