[thread] Internal compiler error when trying to make movable future
Am I doing something wrong in the following code? #include <boost/thread/future.hpp> template<typename T> struct test_node { BOOST_THREAD_MOVABLE_ONLY(test_node) typedef boost::unique_future<test_node> future_node; T value; future_node next; }; (In the "real code" I've defined move constructors etc as well of course, but they don't affect the result so I've omitted them for brevity.) Using boost v1.53 with BOOST_THREAD_VERSION==2 and VS2008 (non C++11 compiler), the above code produces an internal compiler error: 1>t:\boost\boost_1_53_0\boost\type_traits\is_convertible.hpp(484) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1411) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> t:\boost\boost_1_53_0\boost\thread\detail\is_convertible.hpp(22) : see reference to class template instantiation 'boost::is_convertible<From,To>' being compiled 1> with 1> [ 1> From=test_node<int> &, 1> To=boost::detail::thread_move_t<test_node<int>> 1> ] 1> t:\boost\boost_1_53_0\boost\mpl\if.hpp(63) : see reference to class template instantiation 'boost::thread_detail::is_convertible<T1,T2>' being compiled 1> with 1> [ 1> T1=test_node<int> &, 1> T2=boost::detail::thread_move_t<test_node<int>> 1> ] 1> t:\boost\boost_1_53_0\boost\thread\future.hpp(519) : see reference to class template instantiation 'boost::mpl::if_<T1,T2,T3>' being compiled 1> with 1> [ 1> T1=boost::thread_detail::is_convertible<test_node<int> &,boost::detail::thread_move_t<test_node<int>>>, 1> T2=boost::detail::thread_move_t<test_node<int>>, 1> T3=const test_node<int> & 1> ] 1> t:\boost\boost_1_53_0\boost\thread\future.hpp(1398) : see reference to class template instantiation 'boost::detail::future_traits<T>' being compiled 1> with 1> [ 1> T=test_node<int> 1> ] 1> s:\tests\nodetest.cpp(26) : see reference to class template instantiation 'boost::unique_future<R>' being compiled 1> with 1> [ 1> R=test_node<int> 1> ] 1> s:\tests\nodetest.cpp(56) : see reference to class template instantiation 'test_node<T>' being compiled 1> with 1> [ 1> T=int 1> ] The internal error goes away if I remove the MOVABLE_ONLY macro or the future_node instance field. The equivalent move code (using boost::detail::thread_move_t directly) for boost 1.47 compiles and works successfully (but crashes again if I switch to boost 1.53). Is this a regression in boost or am I doing something incorrect somewhere? Does anyone know of a workaround? Note that it does not matter if I try to use Boost.Move syntax instead, as unique_future<> internally uses Boost.Thread's move implementation, which is where things seem to be failing. One possible issue is that I'm trying to declare a future to an incomplete type (because it's self-referential), which is possibly confusing some of the internal checks it wants to do. But again, this usage used to work, and I'm not sure how to fix it given the new boost version. At least not without introducing pointers and heap allocation, which I really didn't want to do.
On 6 Sep 2013 at 14:54, Gavin Lambert wrote:
Am I doing something wrong in the following code? [snip] The internal error goes away if I remove the MOVABLE_ONLY macro or the future_node instance field. The equivalent move code (using boost::detail::thread_move_t directly) for boost 1.47 compiles and works successfully (but crashes again if I switch to boost 1.53).
Is this a regression in boost or am I doing something incorrect somewhere? Does anyone know of a workaround?
As related information, but not solving your specific problem, we had terrible problems in proposed Boost.AFIO with ICEs in Visual Studios preceding 2012. VS2012 and later seems much happier with Boost. A lot of changes have been made to Boost.Thread in recent editions to match APIs with the C++11 standard library. That, inevitably, will cause older compilers some parsing difficulties, even in C++03 mode (e.g. good luck getting VS2010 to not ICE with function types as template parameters). In AFIO we certainly had to do a LOT of rewriting code via trial and error until VS2010 wouldn't ICE. Hope that helps. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Le 06/09/13 18:01, Niall Douglas a écrit :
On 6 Sep 2013 at 14:54, Gavin Lambert wrote:
Am I doing something wrong in the following code? [snip] The internal error goes away if I remove the MOVABLE_ONLY macro or the future_node instance field. The equivalent move code (using boost::detail::thread_move_t directly) for boost 1.47 compiles and works successfully (but crashes again if I switch to boost 1.53).
Is this a regression in boost or am I doing something incorrect somewhere? Does anyone know of a workaround? As related information, but not solving your specific problem, we had terrible problems in proposed Boost.AFIO with ICEs in Visual Studios preceding 2012. VS2012 and later seems much happier with Boost.
A lot of changes have been made to Boost.Thread in recent editions to match APIs with the C++11 standard library. That, inevitably, will cause older compilers some parsing difficulties, even in C++03 mode (e.g. good luck getting VS2010 to not ICE with function types as template parameters). In AFIO we certainly had to do a LOT of rewriting code via trial and error until VS2010 wouldn't ICE.
Hope that helps. Niall, I don't know if you are referring to difficulties with your usage of Boost.Thread or simply VS2010. If you have found some abnormal behavior in Boost.Thread, please state it explicitly, and I will try to help.
Best, Vicente
On 7 Sep 2013 at 10:18, Vicente J. Botet Escriba wrote:
A lot of changes have been made to Boost.Thread in recent editions to match APIs with the C++11 standard library. That, inevitably, will cause older compilers some parsing difficulties, even in C++03 mode (e.g. good luck getting VS2010 to not ICE with function types as template parameters). In AFIO we certainly had to do a LOT of rewriting code via trial and error until VS2010 wouldn't ICE.
Hope that helps. Niall, I don't know if you are referring to difficulties with your usage of Boost.Thread or simply VS2010.
VS2010. Older visual studios don't like a boost::packaged_task<R()> for example, and only work right with the previous boost::packaged_task<R>. This is not the fault of Boost.Thread. There are also lots of gotchas with result_of, including the SFINAE friendly newer version when used on older compilers.
If you have found some abnormal behavior in Boost.Thread, please state it explicitly, and I will try to help.
No, my general, if poorly stated, advice to Gavin was to either use older Boosts with older compilers, or expect to have to trial and error ICE avoidance which is never fun. Or use a newer Visual Studio. Sorry for being unclear. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Le 06/09/13 04:54, Gavin Lambert a écrit :
Am I doing something wrong in the following code?
#include <boost/thread/future.hpp>
template<typename T> struct test_node { BOOST_THREAD_MOVABLE_ONLY(test_node)
typedef boost::unique_future<test_node> future_node;
T value; future_node next; };
(In the "real code" I've defined move constructors etc as well of course, but they don't affect the result so I've omitted them for brevity.)
Using boost v1.53 with BOOST_THREAD_VERSION==2 and VS2008 (non C++11 compiler), the above code produces an internal compiler error:
1>t:\boost\boost_1_53_0\boost\type_traits\is_convertible.hpp(484) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1411) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> t:\boost\boost_1_53_0\boost\thread\detail\is_convertible.hpp(22) : see reference to class template instantiation 'boost::is_convertible<From,To>' being compiled 1> with 1> [ 1> From=test_node<int> &, 1> To=boost::detail::thread_move_t<test_node<int>> 1> ] 1> t:\boost\boost_1_53_0\boost\mpl\if.hpp(63) : see reference to class template instantiation 'boost::thread_detail::is_convertible<T1,T2>' being compiled 1> with 1> [ 1> T1=test_node<int> &, 1> T2=boost::detail::thread_move_t<test_node<int>> 1> ] 1> t:\boost\boost_1_53_0\boost\thread\future.hpp(519) : see reference to class template instantiation 'boost::mpl::if_<T1,T2,T3>' being compiled 1> with 1> [ 1> T1=boost::thread_detail::is_convertible<test_node<int> &,boost::detail::thread_move_t<test_node<int>>>, 1> T2=boost::detail::thread_move_t<test_node<int>>, 1> T3=const test_node<int> & 1> ] 1> t:\boost\boost_1_53_0\boost\thread\future.hpp(1398) : see reference to class template instantiation 'boost::detail::future_traits<T>' being compiled 1> with 1> [ 1> T=test_node<int> 1> ] 1> s:\tests\nodetest.cpp(26) : see reference to class template instantiation 'boost::unique_future<R>' being compiled 1> with 1> [ 1> R=test_node<int> 1> ] 1> s:\tests\nodetest.cpp(56) : see reference to class template instantiation 'test_node<T>' being compiled 1> with 1> [ 1> T=int 1> ]
The internal error goes away if I remove the MOVABLE_ONLY macro or the future_node instance field. The equivalent move code (using boost::detail::thread_move_t directly) for boost 1.47 compiles and works successfully (but crashes again if I switch to boost 1.53).
Is this a regression in boost or am I doing something incorrect somewhere? Does anyone know of a workaround?
Note that it does not matter if I try to use Boost.Move syntax instead, as unique_future<> internally uses Boost.Thread's move implementation, which is where things seem to be failing.
One possible issue is that I'm trying to declare a future to an incomplete type (because it's self-referential), which is possibly confusing some of the internal checks it wants to do. But again, this usage used to work, and I'm not sure how to fix it given the new boost version. At least not without introducing pointers and heap allocation, which I really didn't want to do.
Hi, please,could you post a complete example so that I can try to reproduce it. best, Vicente
On 7/09/2013 19:47, Quoth Vicente J. Botet Escriba:
Am I doing something wrong in the following code?
#include <boost/thread/future.hpp>
template<typename T> struct test_node { BOOST_THREAD_MOVABLE_ONLY(test_node)
typedef boost::unique_future<test_node> future_node;
T value; future_node next; }; [...]
Le 06/09/13 04:54, Gavin Lambert a écrit : please,could you post a complete example so that I can try to reproduce it.
The code above is pretty much a complete example. The only thing further to do is to try to instantiate it (the error output I showed was from trying to instantiate test_node<int>). It's not necessary to interact with it beyond simple instantiation -- that seems to be enough to upset the compiler. FWIW, I've worked around the issue for the moment by storing a std::auto_ptr<future_node> as the "next" field value instead of using it directly. I think that confirms my hypothesis that it's getting upset at trying to evaluate metadata on an incomplete type. (I'd use a std::unique_ptr instead if I were targetting C++11, of course. I was kinda surprised I couldn't find a unique_ptr emulation in boost, actually.)
On 09/09/2013 12:51 AM, Gavin Lambert wrote:
course. I was kinda surprised I couldn't find a unique_ptr emulation in boost, actually.)
AFAIK, it is not possible to make a fully compliant unique_ptr with C++03. However, there is a limited emulation in <boost/interprocess/unique_ptr.hpp>. There is work-in-progress on a more fully supported version. See https://github.com/helloworld922/unique_ptr
participants (5)
-
Bjorn Reese -
Gavin Lambert -
Niall Douglas -
Vicente J. Botet Escriba