VC2013 1.55 beta failures
Hi, Building 1.55 beta keeps failing on VC2013 RC. Trunk fails too IIRC. compile-c-c++ bin.v2\libs\date_time\build\msvc-12.0\debug\link-static\threading-multi\gregorian\greg_month.obj greg_month.cpp C:\VC\boost_1_55_0b1\boost/iterator/detail/facade_iterator_category.hpp(166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' C:\VC\boost_1_55_0b1\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/detail/facade_iterator_category.hpp(193) : see reference to class template instantiation 'boost::mpl::eval_if<boost::detail::is_iterator_category<CategoryOrTraversal>,boost::mpl::identity<boost::forward_traversal_tag>,boost::detail::facade_iterator_category_impl<CategoryOrTra versal,ValueParam,Reference>>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/iterator_facade.hpp(104) : see reference to class template instantiation 'boost::detail::facade_iterator_category<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/iterator_facade.hpp(620) : see reference to class template instantiation 'boost::detail::iterator_facade_types<Value,CategoryOrTraversal,Reference,Difference>' being compiled with [ Value=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , CategoryOrTraversal=boost::forward_traversal_tag , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & , Difference=ptrdiff_t ] C:\VC\boost_1_55_0b1\boost/token_iterator.hpp(40) : see reference to class template instantiation 'boost::iterator_facade<boost::token_iterator<TokenizerFunc,Iterator,Type>,Type,boost::forward_traversal_tag,const Type &,ptrdiff_t>' being compiled with [ TokenizerFunc=char_separator_type , Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>> , Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ] C:\VC\boost_1_55_0b1\boost/date_time/date_parsing.hpp(132) : see reference to class template instantiation 'boost::token_iterator<TokenizerFunc,Iterator,Type>' being compiled with [ TokenizerFunc=char_separator_type , Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>> , Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ] C:\VC\boost_1_55_0b1\boost/date_time/gregorian/parsers.hpp(30) : see reference to function template instantiation 'date_type boost::date_time::parse_date<boost::gregorian::date>(const std::string &,int)' being compiled with [
Am 15.10.2013, 14:59 Uhr, schrieb Olaf van der Spek <olaf@xwis.net>:
Building 1.55 beta keeps failing on VC2013 RC.
This issue has already been fixed in trunk in May: https://svn.boost.org/trac/boost/changeset/84443 Could someone please merge r84443 to the release branch?
Trunk fails too IIRC.
The compile failure in trunk is a different issue, this seems to be a bug in VC2013 RC that has already been reported on Microsoft Connect several times. Regards, Christian
On 16.10.2013. 19:59, Stephan T. Lavavej wrote:
[Christian Hägele]
The compile failure in trunk is a different issue, this seems to be a bug in VC2013 RC that has already been reported on Microsoft Connect several times.
Which bug?
Already reported several times... https://connect.microsoft.com/VisualStudio/feedback/details/805028/vs2013-rc... ...supposedly this was already forwarded to your front end team...try to provide at least a workaround before 1.55 ships (as I suppose it is too late for MSVC12 RTM)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On 16 Oct 2013 at 20:13, Domagoj Saric wrote:
On 16.10.2013. 19:59, Stephan T. Lavavej wrote:
[Christian Hägele]
The compile failure in trunk is a different issue, this seems to be a bug in VC2013 RC that has already been reported on Microsoft Connect several times.
Which bug?
Already reported several times... https://connect.microsoft.com/VisualStudio/feedback/details/805028/vs2013-rc... ...supposedly this was already forwarded to your front end team...try to provide at least a workaround before 1.55 ships (as I suppose it is too late for MSVC12 RTM)...
I have discovered a workaround for the bug. In the header file which #defines BOOST_concept, after the #define do: #ifndef BOOST_concept #error foo #endif This seems to "lock in" the macro definition of BOOST_concept into the compiland. Definitely a compiler preprocessor bug this. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
[Domagoj Saric]
Already reported several times... https://connect.microsoft.com/VisualStudio/feedback/details/805028/vs2013-rc... ...supposedly this was already forwarded to your front end team...try to provide at least a workaround before 1.55 ships (as I suppose it is too late for MSVC12 RTM)...
Thanks - this bug (DevDiv#798789 internally) is suspected to be a dupe of http://connect.microsoft.com/VisualStudio/feedback/details/800200/preprocess... (DevDiv#777751 internally) which was fixed for VC 2013 RTM. STL
On 16.10.2013. 20:33, Stephan T. Lavavej wrote:
[Domagoj Saric]
Already reported several times... https://connect.microsoft.com/VisualStudio/feedback/details/805028/vs2013-rc... ...supposedly this was already forwarded to your front end team...try to provide at least a workaround before 1.55 ships (as I suppose it is too late for MSVC12 RTM)...
Thanks - this bug (DevDiv#798789 internally) is suspected to be a dupe of http://connect.microsoft.com/VisualStudio/feedback/details/800200/preprocess... (DevDiv#777751 internally) which was fixed for VC 2013 RTM.
Suspect? It's not like you cannot test it... -- Domagoj Saric Software Architect www.LittleEndian.com
[STL]
Thanks - this bug (DevDiv#798789 internally) is suspected to be a dupe of http://connect.microsoft.com/VisualStudio/feedback/details/800200/preprocess... (DevDiv#777751 internally) which was fixed for VC 2013 RTM.
[Domagoj Saric]
Suspect? It's not like you cannot test it...
It's currently assigned to a tester to verify, since it was reported as "build Boost and it explodes" instead of with a reduced test case. STL
On 17 Oct 2013 at 18:23, Stephan T. Lavavej wrote:
It's currently assigned to a tester to verify, since it was reported as "build Boost and it explodes" instead of with a reduced test case.
I did spend 30 minutes trying to reduce it, but in the end my time isn't free. Boost is big and important enough that any compiler would have it in its functional test suite anyway, so I figured MS would already have a framework ready and waiting. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Christian Hägele <haegele <at> teamviewer.com> writes:
This issue has already been fixed in trunk in May:
Could someone please merge r84443 to the release branch?
Could this single-character fix be merged before the final 1.55 release? This error causes almost all libraries to fail compiling with VC++ 2013.
On Oct 15, 2013, at 5:59 AM, Olaf van der Spek <olaf@xwis.net> wrote:
Hi,
Building 1.55 beta keeps failing on VC2013 RC.
So I see that VC2013 is no longer RC, but has been released. http://blogs.msdn.com/b/visualstudio/archive/2013/10/17/visual-studio-2013-r... Has anyone tried the 1.55.0 beta with the released version of VC2013? What needs to be done to support this in the 1.55 release? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 17-10-2013 18:02, Marshall Clow wrote:
On Oct 15, 2013, at 5:59 AM, Olaf van der Spek <olaf@xwis.net> wrote:
Hi,
Building 1.55 beta keeps failing on VC2013 RC.
So I see that VC2013 is no longer RC, but has been released. http://blogs.msdn.com/b/visualstudio/archive/2013/10/17/visual-studio-2013-r...
Has anyone tried the 1.55.0 beta with the released version of VC2013?
What needs to be done to support this in the 1.55 release?
https://svn.boost.org/trac/boost/ticket/9249 Has this fix been merged into release yet?
On 17 Oct 2013 at 9:02, Marshall Clow wrote:
So I see that VC2013 is no longer RC, but has been released. http://blogs.msdn.com/b/visualstudio/archive/2013/10/17/visual-studio-2013-r...
Has anyone tried the 1.55.0 beta with the released version of VC2013?
What needs to be done to support this in the 1.55 release?
I won't get a chance to test VS2013 RTM till late next week after when I get back from Seattle, but apart from Boost.Config having to turn off variadic templates on VS2013 due to breakage in Boost.Signals2 and a few other minor places, it was all looking very good indeed in the RC. If that preprocessor bug is still extant in the RTM, I posted a workaround a few days ago. Otherwise to my knowledge it's good to go, and I've been using VS2013 with Boost since its first beta. Boost.AFIO was mostly written and debugged using VS2012 Nov CTP and VS2013 in fact because Windows has a very decent async file i/o framework. A good Visual Studio release, no doubt. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
[Niall Douglas]
apart from Boost.Config having to turn off variadic templates on VS2013 due to breakage in Boost.Signals2 and a few other minor places, it was all looking very good indeed in the RC.
Argh. Have any MS Connect bugs been filed to track those variadic template problems? I wasn't aware that Boost had to turn them off - that's a big deal. STL
On 17 Oct 2013 at 18:25, Stephan T. Lavavej wrote:
[Niall Douglas]
apart from Boost.Config having to turn off variadic templates on VS2013 due to breakage in Boost.Signals2 and a few other minor places, it was all looking very good indeed in the RC.
Argh. Have any MS Connect bugs been filed to track those variadic template problems? I wasn't aware that Boost had to turn them off - that's a big deal.
No one has had the time yet to look into whether it's VS2013 or undefined behaviour assumptions by those bits of Boost which break. It could be either, or both. It could even be as simple as telling those bits of code to stop using the special "I am using MSVC" code path i.e. a simple #if fix. I think the lack of attention here is mainly unfortunate timing: Boost v1.55 was locked down for release some time ago, and VS2013 was being released in parallel. As an aside, I am very surprised that porting Boost to VS2013 with all VS2013's features turned on wasn't part and parcel of VS2013 release testing. Boost is surely an excellent way of testing new C++11 feature implementations. FYI, binaries produced by VS2013 with variadic templates on are about 10% faster than with VS2012, I assume due to more compact output. It's a huge win for debugging sanity too. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On 17 Oct 2013 at 15:37, Niall Douglas wrote:
apart from Boost.Config having to turn off variadic templates on VS2013 due to breakage in Boost.Signals2 and a few other minor places, it was all looking very good indeed in the RC.
Argh. Have any MS Connect bugs been filed to track those variadic template problems? I wasn't aware that Boost had to turn them off - that's a big deal.
FYI after wasting three hours fixing the Windows 8.1 upgrade making my machine unbootable (tip to anyone else here: uninstall and *purge* all graphics drivers, including those for Intel onboard graphics and MVP Virtu, before doing the upgrade), I had a spare half hour to try VS2013 RTM. In short: that preprocessor bug looks fixed. Good news. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Stephan T. Lavavej <stl <at> exchange.microsoft.com> writes:
[Niall Douglas]
apart from Boost.Config having to turn off variadic templates
on VS2013 due to breakage in Boost.Signals2 and a few other
minor places, it was all looking very good indeed in the RC.
Argh. Have any MS Connect bugs been filed to track those variadic template problems? I wasn't aware that
Boost had to turn them off - that's a big deal.
I have finally found the issue. signals2::slot has 2 constructors: slot<F>(const F &f) { init_slot_function(f); } slot<BindArgs...>(const BindArgs &...args) { init_slot_function(boost::bind(args...)); } MSVC12 always chooses the variadic constructor, so calling it with boost::bind(...) always tries to call boost::bind(boost::bind(...)). If I understand the example in 14.8.2.4.8 of the January 2012 working draft correctly, it should be the other way around, shouldn't it?
[Marcel Raad]
slot<F>(const F &f) slot<BindArgs...>(const BindArgs &...args) MSVC12 always chooses the variadic constructor
Wow, that's a bug. I've filed DevDiv#807268 "meow(const T&) should be considered to be more specialized than meow(const Args&...)" in our internal database with a reduced repro: C:\Temp>type meow.cpp #include <stdio.h> template <typename T> void meow(const T&) { puts("meow(const T&), GOOD"); } template <typename... Args> void meow(const Args&...) { puts("meow(const Args&...), BAD"); } int main() { meow(1729); } C:\Temp>cl /EHsc /nologo /W4 meow.cpp meow.cpp C:\Temp>meow meow(const Args&...), BAD Thanks, STL
Stephan T. Lavavej <stl <at> exchange.microsoft.com> writes:
I've filed DevDiv#807268 "meow(const T&) should be considered to be more specialized
than meow(const Args&...)" in our internal database
I have also opened a bug report on Microsoft Connect (ID 806150) with almost the same repro, perhaps you can mark it as a duplicate.
On Tue, Oct 22, 2013 at 2:50 PM, Stephan T. Lavavej < stl@exchange.microsoft.com> wrote:
[Marcel Raad]
slot<F>(const F &f) slot<BindArgs...>(const BindArgs &...args) MSVC12 always chooses the variadic constructor
Wow, that's a bug. I've filed DevDiv#807268 "meow(const T&) should be considered to be more specialized than meow(const Args&...)" in our internal database with a reduced repro:
C:\Temp>type meow.cpp #include <stdio.h>
template <typename T> void meow(const T&) { puts("meow(const T&), GOOD"); }
template <typename... Args> void meow(const Args&...) { puts("meow(const Args&...), BAD"); }
int main() { meow(1729); }
C:\Temp>cl /EHsc /nologo /W4 meow.cpp meow.cpp
C:\Temp>meow meow(const Args&...), BAD
Thanks STL for following up on this. I've like help translating this bug into what action Boost.Config should take for Boost 1.55. Currently we define BOOST_NO_CXX11_VARIADIC_TEMPLATES in trunk so that signals2 and its dependencies pass their regression tests. Should we continue to define BOOST_NO_CXX11_VARIADIC_TEMPLATES for VC++ 2013, or should we not define it and get signals2 working with a problem specific workaround? I have a weak preference for not defining it, but would very much like to hear opinions for anyone, but particularly release managers. Whatever we do, I want to do it right away so that there is time to merge into release for 1.55. Thanks, --Beman
Beman Dawes wrote:
Should we continue to define BOOST_NO_CXX11_VARIADIC_TEMPLATES for VC++ 2013, or should we not define it and get signals2 working with a problem specific workaround?
Get signals2 working, I'd say. The variadic constructor is already a bit broken in that it incorrectly accepts zero arguments, so why not just constrain it to two or more. template<class A1, class A2, class... Args> slot( A1 const& a1, A2 const& a2, Args const&... args ) { ... }
On Wed, Oct 23, 2013 at 12:02 PM, Peter Dimov <lists@pdimov.com> wrote:
Beman Dawes wrote:
Should we continue to define BOOST_NO_CXX11_VARIADIC_TEMPLATES for VC++ 2013, or should we not define it and get signals2 working with a problem specific workaround?
Get signals2 working, I'd say. The variadic constructor is already a bit broken in that it incorrectly accepts zero arguments, so why not just constrain it to two or more.
template<class A1, class A2, class... Args> slot( A1 const& a1, A2 const& a2, Args const&... args ) { ... }
That sounds fine by me. I can commit the change to trunk tonight, should I also commit it to release, or wait for tests to cycle? -- Frank
On Wed, Oct 23, 2013 at 2:34 PM, Frank Mori Hess <fmh6jj@gmail.com> wrote:
On Wed, Oct 23, 2013 at 12:02 PM, Peter Dimov <lists@pdimov.com> wrote:
Beman Dawes wrote:
Should we continue to define BOOST_NO_CXX11_VARIADIC_TEMPLATES for VC++ 2013, or should we not define it and get signals2 working with a problem specific workaround?
Get signals2 working, I'd say. The variadic constructor is already a bit broken in that it incorrectly accepts zero arguments, so why not just constrain it to two or more.
template<class A1, class A2, class... Args> slot( A1 const& a1, A2 const& a2, Args const&... args ) { ... }
That sounds fine by me. I can commit the change to trunk tonight, should I also commit it to release, or wait for tests to cycle?
I've just committed (r86408), the BOOST_NO_CXX11_VARIADIC_TEMPLATES removal for VS 2013, but will wait roughly 24-hours to give tests a chance to cycle before merging to trunk. Why don't you do the same? That still meets the Monday for merging to release without having to ask permission. Thanks, --Beman
Trunk tests on msvc-12.0 have *finally* completed. On Wed, Oct 23, 2013 at 3:11 PM, Beman Dawes <bdawes@acm.org> wrote:
On Wed, Oct 23, 2013 at 2:34 PM, Frank Mori Hess <fmh6jj@gmail.com> wrote:
Beman Dawes wrote:
Should we continue to define BOOST_NO_CXX11_VARIADIC_TEMPLATES for
VC++
2013, or should we not define it and get signals2 working with a
On Wed, Oct 23, 2013 at 12:02 PM, Peter Dimov <lists@pdimov.com> wrote: problem
specific workaround?
Get signals2 working, I'd say. The variadic constructor is already a bit broken in that it incorrectly accepts zero arguments, so why not just constrain it to two or more.
template<class A1, class A2, class... Args> slot( A1 const& a1, A2 const& a2, Args const&... args ) { ... }
That sounds fine by me. I can commit the change to trunk tonight, should I also commit it to release, or wait for tests to cycle?
I've just committed (r86408), the BOOST_NO_CXX11_VARIADIC_TEMPLATES removal for VS 2013, but will wait roughly 24-hours to give tests a chance to cycle before merging to trunk. Why don't you do the same? That still meets the Monday for merging to release without having to ask permission.
Thanks,
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peter Dimov <lists <at> pdimov.com> writes:
Get signals2 working, I'd say. The variadic constructor is already a bit
broken in that it incorrectly accepts zero arguments, so why not just
constrain it to two or more.
Yes, working around the template function resolution failures in the boost code path with variadic templates should be easier than working around the compiler crashes in the code path without them. In the libraries that I am using, the signals2::slot constructor issue is the only compile error in the code path with variadic templates enabled.
On Wed, Oct 23, 2013 at 5:48 PM, Beman Dawes <bdawes@acm.org> wrote:
Should we continue to define BOOST_NO_CXX11_VARIADIC_TEMPLATES for VC++ 2013, or should we not define it and get signals2 working with a problem specific workaround?
I have a weak preference for not defining it, but would very much like to hear opinions for anyone, but particularly release managers.
My humble opinion is to not define it and implement workarounds in specific libraries until VC is fixed. I'm compiling boost trunk again right now, with variadic templates activated, to confirm if it would hurt my project but last time I tried it was not the main issue. That being said, did someone tried the test suite with vc12 already with variadic templates activated? If not I'm willing to try after I've finished checking if my project compiles.
[Marcel Raad]
slot<F>(const F &f) slot<BindArgs...>(const BindArgs &...args) MSVC12 always chooses the variadic constructor
[STL]
Wow, that's a bug. I've filed DevDiv#807268 "meow(const T&) should be considered to be more specialized than meow(const Args&...)" in our internal database with a reduced repro
This has been fixed for the next major version of VC. Note that the fix isn't present in the Nov 2013 CTP/alpha. Thanks, STL
Niall Douglas <s_sourceforge <at> nedprod.com> writes:
On 17 Oct 2013 at 9:02, Marshall Clow wrote:
What needs to be done to support this in the 1.55 release?
I won't get a chance to test VS2013 RTM till late next week after
when I get back from Seattle, but apart from Boost.Config having to
turn off variadic templates on VS2013 due to breakage in
Boost.Signals2 and a few other minor places, it was all looking very
good indeed in the RC.
Trunk compiles fine with VS2013 RTM. The release branch is still missing r84443. If I remove the "#define BOOST_NO_CXX11_VARIADIC_TEMPLATES", the only file that does not compile seems to be boost/bind/bind.hpp.
Marcel Raad wrote:
If I remove the "#define BOOST_NO_CXX11_VARIADIC_TEMPLATES", the only file that does not compile seems to be boost/bind/bind.hpp.
That's odd, because bind.hpp doesn't use variadic templates and does not contain references to this macro. What errors are you getting?
Peter Dimov <lists <at> pdimov.com> writes:
Marcel Raad wrote:
If I remove the "#define BOOST_NO_CXX11_VARIADIC_TEMPLATES", the only file
that does not compile seems to be boost/bind/bind.hpp.
That's odd, because bind.hpp doesn't use variadic templates and does not
contain references to this macro. What errors are you getting?
Sorry, I just noticed that I only get compile errors if I call boost::signals2::signal<>::connect with the result of boost::bind, so the problem indeed seems to be boost::signals2. I get the following errors: boost/bind/bind.hpp(303): error C2784: 'result_traits<R,F>::type boost::_bi::list0::operator [](const boost::_bi::bind_t<R,F,L> &) const' : could not deduce template argument for 'overloaded function type' from 'overloaded function type' boost/bind/bind.hpp(178) : see declaration of 'boost::_bi::list0::operator []' boost/bind/bind.hpp(303): error C2784: 'result_traits<R,F>::type boost::_bi::list0::operator [](boost::_bi::bind_t<R,F,L> &) const' : could not deduce template argument for 'overloaded function type' from 'overloaded function type' boost/bind/bind.hpp(176) : see declaration of 'boost::_bi::list0::operator []' boost/bind/bind.hpp(303): error C2784: 'T &boost::_bi::list0::operator [] (const boost::reference_wrapper<T> &) const' : could not deduce template argument for 'overloaded function type' from 'overloaded function type' boost/bind/bind.hpp(174) : see declaration of 'boost::_bi::list0::operator []' boost/bind/bind.hpp(303): error C2784: 'const T &boost::_bi::list0::operator [](const boost::_bi::value<T> &) const' : could not deduce template argument for 'overloaded function type' from 'overloaded function type' boost/bind/bind.hpp(172) : see declaration of 'boost::_bi::list0::operator []' boost/bind/bind.hpp(303): error C2784: 'T &boost::_bi::list0::operator [] (boost::_bi::value<T> &) const' : could not deduce template argument for 'overloaded function type' from 'overloaded function type' boost/bind/bind.hpp(170) : see declaration of 'boost::_bi::list0::operator []' boost/bind/bind.hpp(303): error C2676: binary '[' : 'boost::_bi::list0' does not define this operator or a conversion to a type acceptable to the predefined operator boost/bind/bind.hpp(303): error C2064: term does not evaluate to a function taking 1 arguments class does not define an 'operator()' or a user defined conversion operator to a pointer-to-function or reference-to-function that takes appropriate number of arguments
Marcel Raad wrote:
Sorry, I just noticed that I only get compile errors if I call boost::signals2::signal<>::connect with the result of boost::bind, so the problem indeed seems to be boost::signals2.
I get the following errors: [...]
These errors are, I think, caused by trying to call something like boost::bind( f, _1 ) (which needs an argument) with an empty argument list, but without more information about the source line causing the errors, I can't be sure. I don't know why these only appear when BOOST_NO_CXX11_VARIADIC_TEMPLATES is not defined. Perhaps Signals2 has a different code path for variadic templates? Or perhaps your code does something different when BOOST_NO_CXX11_VARIADIC_TEMPLATES is not defined?
On Fri, Oct 18, 2013 at 10:00 AM, Peter Dimov <lists@pdimov.com> wrote:
Marcel Raad wrote:
Sorry, I just noticed that I only get compile errors if I call boost::signals2::signal<>::**connect with the result of boost::bind, so the problem indeed seems to be boost::signals2.
I get the following errors:
[...]
These errors are, I think, caused by trying to call something like boost::bind( f, _1 ) (which needs an argument) with an empty argument list, but without more information about the source line causing the errors, I can't be sure.
I don't know why these only appear when BOOST_NO_CXX11_VARIADIC_TEMPLATES is not defined. Perhaps Signals2 has a different code path for variadic templates? Or perhaps your code does something different when BOOST_NO_CXX11_VARIADIC_TEMPLATES is not defined?
Yes, signals2 does have multiple different code paths for variadics. The problem is apparently that it should be testing for more than BOOST_NO_CXX11_VARIADIC_TEMPLATES, but we don't yet know exactly what more. Suggestions have been expression SFINAE or a decltype issue. --Beman
I installed VS2013, compiled boost trunk r86347 (no apparent errors but I didn't do a full log check) I found a compiler crash if you do (full repro case): #include <boost/thread/synchronized_value.hpp> #include <boost/property_tree/ptree.hpp> boost::synchronized_value<boost::property_tree::ptree> tree; That's the whole code of the file. Which triggers: 1> config.cpp 1>e:\projects\sdk\boost\boost\include\boost-1_55\boost\thread\synchronized_value.hpp(401): fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\types.c', line 12852) 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> e:\projects\games\netrush\netrush_projects\projects\netrush\system\core\config.cpp(151) : see reference to class template instantiation 'boost::synchronized_value<boost::property_tree::ptree,boost::mutex>' being compiled Build has been canceled. It might be related to a compiler crash I reported there: http://connect.microsoft.com/VisualStudio/feedback/details/802157/compiler-c... I'm not sure if it would be a good idea to make this a test. I'll replace this code by a separate mutex and will report if I find other problems. Note that I didn't have this problem with a previous boost trunk release from july (can't find the specific revision right now), compiled with the RC. W<http://connect.microsoft.com/VisualStudio/feedback/details/802157/compiler-crash-mixing-boost-synchronized-value-and-boost-property-tree>hen I got VS2013 RTM I compiled my project with boost trunk from july compiled by the RC, it worked as before, so I don't know if the change was in boost or the compiler or both.
I got the same crash using the following full code (using boost trunk r86347): #include <boost/thread/synchronized_value.hpp> boost::synchronized_value<int> foo; Which produce the following error (ignore the file name, it contains exactly the code above): 1> clock.cpp 1>e:\projects\sdk\boost\boost\include\boost-1_55\boost\thread\synchronized_value.hpp(401): fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\types.c', line 12852) 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> e:\projects\games\netrush\netrush_projects\projects\netrush\system\core\clock.hpp(120) : see reference to class template instantiation 'boost::synchronized_value<int,boost::mutex>' being compiled Build has been canceled. I'm starting to think both vs2013 and synchronized_value code might be causing this errror. I'll report in both bug trackers.
I reported the issue there: https://svn.boost.org/trac/boost/ticket/9266 Basically, synchronized_value is broken with VC12 because boost assume it's implementation of variadic templates is broken (BOOST_NO_CXX11_VARIADIC_TEMPLATES is defined) because of signals not working correctly with VC12 RC as pointed before here. It looks like we have some kind of conflict here. However, I'm surprised the non-variadic code in synchronized_value does crash the vc12 compiler.
[Klaim - Joël Lamotte]
fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\types.c', line 12852)
I'm starting to think both vs2013 and synchronized_value code might be causing this errror. I'll report in both bug trackers.
Internal Compiler Errors are by definition compiler bugs (doesn't matter if your code is correct or incorrect, although obviously ICE-on-valid is worse than ICE-on-invalid). Thanks for reporting this one. STL
On Fri, Oct 18, 2013 at 8:20 PM, Stephan T. Lavavej < stl@exchange.microsoft.com> wrote:
fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\types.c', line
[Klaim - Joël Lamotte] 12852)
I'm starting to think both vs2013 and synchronized_value code might be causing this errror. I'll report in both bug trackers.
Internal Compiler Errors are by definition compiler bugs (doesn't matter if your code is correct or incorrect, although obviously ICE-on-valid is worse than ICE-on-invalid). Thanks for reporting this one.
Indeed. I reported it both in the comment of the bug I found in the RC ( https://connect.microsoft.com/VisualStudio/feedback/details/802157/compiler-... ) and also reported it in a separate bug so that it's tagged with the RTM: https://connect.microsoft.com/VisualStudio/feedback/details/805862/compiler-...
I experimented the following: In a fresh copy of boost trunk r86347, I made the following change: 1. go in boost/config/compiler/visualc.hpp 2. replace // C++11 features supported by VC++ 12 (aka 2013). // #if _MSC_FULL_VER < 180020827 # define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS # define BOOST_NO_CXX11_DELETED_FUNCTIONS # define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS # define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS # define BOOST_NO_CXX11_RAW_LITERALS # define BOOST_NO_CXX11_TEMPLATE_ALIASES # define BOOST_NO_CXX11_TRAILING_RESULT_TYPES # define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX #endif // variadic templates are supposed to be supported by VC++ 12 // but VC++ 12 RC variadic support is causing boost regression // test failures for signals2 and several of its dependencies. #define BOOST_NO_CXX11_VARIADIC_TEMPLATES by // C++11 features supported by VC++ 12 (aka 2013). // #if _MSC_FULL_VER < 180020827 # define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS # define BOOST_NO_CXX11_DELETED_FUNCTIONS # define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS # define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS # define BOOST_NO_CXX11_RAW_LITERALS # define BOOST_NO_CXX11_TEMPLATE_ALIASES # define BOOST_NO_CXX11_TRAILING_RESULT_TYPES # define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX // variadic templates are supposed to be supported by VC++ 12 // but VC++ 12 RC variadic support is causing boost regression // test failures for signals2 and several of its dependencies. # define BOOST_NO_CXX11_VARIADIC_TEMPLATES #endif 3. compile boost with vc12 - no error in the log, I checked this time but I didn't try to run the tests; Doing this fixes synchronized_value for me. However, there is a strange compilation error I can't decipher with flat_set and flat_map. Compiling: #include <boost/container/flat_map.hpp> boost::container::flat_map<int, int> foo; Generates the following error (please ignore the file names, I replaced all the code by the code above): 1>e:\projects\sdk\boost\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(200): error C2228: left of '.select_on_container_copy_construction' must have class/struct/union 1> type is 'boost::move_detail::add_rvalue_reference<U>::type' 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(276) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction_impl<Fun,true,>' being compiled 1> with 1> [ 1> Fun=std::allocator<std::pair<int,int>> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\allocator_traits.hpp(262) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction<const Alloc,>' being compiled 1> with 1> [ 1> Alloc=std::allocator<std::pair<int,int>> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\flat_map.hpp(113) : see reference to class template instantiation 'boost::container::allocator_traits<Allocator>' being compiled 1> with 1> [ 1> Allocator=std::allocator<std::pair<int,int>> 1> ] 1> e:\projects\games\netrush\netrush_projects\projects\netrush\system\view\tests\anyvalueset.cpp(288) : see reference to class template instantiation 'boost::container::flat_map<int,int,std::less<Key>,std::allocator<std::pair<Key,T>>>' being compiled 1> with 1> [ 1> Key=int 1> , T=int 1> ] Build has been canceled. With the following code: #include <boost/container/flat_set.hpp> boost::container::flat_set<int, int> foo; I get these errors: 1>e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\detail\flat_tree.hpp(50): error C2516: 'Compare' : is not a legal base class 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\detail\flat_tree.hpp(110) : see declaration of 'Compare' 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\detail\flat_tree.hpp(110) : see reference to class template instantiation 'boost::container::container_detail::flat_tree_value_compare<Compare,Value,KeyOfValue>' being compiled 1> with 1> [ 1> Compare=int 1> , Value=int 1> , KeyOfValue=boost::container::container_detail::identity<int> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\detail\flat_tree.hpp(170) : see reference to class template instantiation 'boost::container::container_detail::flat_tree<Key,Key,boost::container::container_detail::identity<Key>,Compare,Allocator>::Data' being compiled 1> with 1> [ 1> Key=int 1> , Compare=int 1> , Allocator=std::allocator<int> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\flat_set.hpp(75) : see reference to class template instantiation 'boost::container::container_detail::flat_tree<Key,Key,boost::container::container_detail::identity<Key>,Compare,Allocator>' being compiled 1> with 1> [ 1> Key=int 1> , Compare=int 1> , Allocator=std::allocator<int> 1> ] 1> e:\projects\games\netrush\netrush_projects\projects\netrush\system\view\tests\anyvalueset.cpp(288) : see reference to class template instantiation 'boost::container::flat_set<int,int,std::allocator<Key>>' being compiled 1> with 1> [ 1> Key=int 1> ] 1>e:\projects\sdk\boost\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(200): error C2228: left of '.select_on_container_copy_construction' must have class/struct/union 1> type is 'boost::move_detail::add_rvalue_reference<U>::type' 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(276) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction_impl<Fun,true,>' being compiled 1> with 1> [ 1> Fun=std::allocator<int> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\allocator_traits.hpp(262) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction<const Alloc,>' being compiled 1> with 1> [ 1> Alloc=std::allocator<int> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\vector.hpp(279) : see reference to class template instantiation 'boost::container::allocator_traits<Allocator>' being compiled 1> with 1> [ 1> Allocator=std::allocator<int> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\vector.hpp(550) : see reference to class template instantiation 'boost::container::container_detail::vector_alloc_holder<Allocator,boost::container::container_detail::integral_constant<unsigned int,1>>' being compiled 1> with 1> [ 1> Allocator=std::allocator<int> 1> ] 1> e:\projects\sdk\boost\boost\include\boost-1_55\boost\container\detail\flat_tree.hpp(167) : see reference to class template instantiation 'boost::container::vector<Value,A>' being compiled 1> with 1> [ 1> Value=int 1> , A=std::allocator<int> 1> ] Build has been canceled. So I'm not sure if it's related to variadic templates activated or not but it don't look so. I'll reported this in the tracker: https://svn.boost.org/trac/boost/ticket/9267
[Klaim - Joël Lamotte]
// C++11 features supported by VC++ 12 (aka 2013). // #if _MSC_FULL_VER < 180020827 # define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS # define BOOST_NO_CXX11_DELETED_FUNCTIONS # define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS # define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS # define BOOST_NO_CXX11_RAW_LITERALS # define BOOST_NO_CXX11_TEMPLATE_ALIASES # define BOOST_NO_CXX11_TRAILING_RESULT_TYPES # define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX // variadic templates are supposed to be supported by VC++ 12 // but VC++ 12 RC variadic support is causing boost regression // test failures for signals2 and several of its dependencies. # define BOOST_NO_CXX11_VARIADIC_TEMPLATES #endif
Trailing return types were supported in VC 2010. STL
On Fri, Oct 18, 2013 at 9:24 PM, Stephan T. Lavavej < stl@exchange.microsoft.com> wrote:
Trailing return types were supported in VC 2010.
I don't remember why they are still deactivated but my guess would be because of issues related to auto implementation in msvc. Or it's just have been forgot.
On Wed, Oct 23, 2013 at 3:07 PM, Marcel Raad <raad@teamviewer.com> wrote:
boost::container::flat_set<int, int> foo;
Shouldn't it be flat_set<int> or flat_set<int, std::less<int>>?
Oups, yes, sorry when I did that I copy-pasted the flat_map test. flat_set<SomeStruct> triggered the same problem anyway in my code base, but right now I don't have the same boost build so I can't try it again. I'll try it again soon (activating variadic templates with vc12) see if recent trunk have the same issue. With luck, my use of signals2 is simple enough to make my project build anyway.
Beman Dawes <bdawes <at> acm.org> writes:
Yes, signals2 does have multiple different code paths for variadics. The
problem is apparently that it should be testing for more
than BOOST_NO_CXX11_VARIADIC_TEMPLATES, but we don't yet know exactly what
more. Suggestions have been expression SFINAE or a decltype issue.
The problem seems to be somewhere in the constructor of boost::signals2::slot. The code which led to compile errors was: boost::signals2::signal<void (const std::wstring &, int)> mySignal; mySignal.connect(boost::bind(&SomeMemberFunction, this, _1, _2)); Changing it to the following code compiles: boost::signals2::signal<void (const std::wstring &, int)> mySignal; boost::signals2::slot<void (const std::wstring&, int), boost::function<void (const std::wstring&, int)>> mySlot(&SomeMemberfunction, this, _1, _2);
Marcel Raad <raad <at> teamviewer.com> writes:
Changing it to the following code compiles:
boost::signals2::signal<void (const std::wstring &, int)> mySignal;
boost::signals2::slot<void (const std::wstring&, int), boost::function<void
(const std::wstring&, int)>> mySlot(&SomeMemberfunction, this, _1, _2);
Sorry, I forgot the last line: mySignal.connect(mySlot);
On Fri, Oct 18, 2013 at 10:00 AM, Peter Dimov <lists@pdimov.com> wrote:
I don't know why these only appear when BOOST_NO_CXX11_VARIADIC_**TEMPLATES is not defined. Perhaps Signals2 has a different code path for variadic templates?
Yes, Signals2 does have a significantly different code path for variadic templates. -- Frank
On Thu, Oct 17, 2013 at 4:02 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
On Oct 15, 2013, at 5:59 AM, Olaf van der Spek <olaf@xwis.net> wrote:
Hi,
Building 1.55 beta keeps failing on VC2013 RC.
So I see that VC2013 is no longer RC, but has been released.
http://blogs.msdn.com/b/visualstudio/archive/2013/10/17/visual-studio-2013-r...
Has anyone tried the 1.55.0 beta with the released version of VC2013?
What needs to be done to support this in the 1.55 release?
-- Marshall
Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
I've got a fresh VC2013 (it only showed up on the MSDN servers a few minutes before you wrote this!) installed and am seeing *a lot* of errors with 1.55 beta.
See the output of the failures here (6MB): http://boost.teeks99.com/misc/boost_1_55_0b1-32bitlog.txt
On 18 Oct 2013 at 1:31, Tom Kent wrote:
I've got a fresh VC2013 (it only showed up on the MSDN servers a few minutes before you wrote this!) installed and am seeing *a lot* of errors with 1.55 beta.
See the output of the failures here (6MB): http://boost.teeks99.com/misc/boost_1_55_0b1-32bitlog.txt
Try trunk. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Fri, Oct 18, 2013 at 3:41 AM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
On 18 Oct 2013 at 1:31, Tom Kent wrote:
I've got a fresh VC2013 (it only showed up on the MSDN servers a few minutes before you wrote this!) installed and am seeing *a lot* of errors with 1.55 beta.
See the output of the failures here (6MB): http://boost.teeks99.com/misc/boost_1_55_0b1-32bitlog.txt
Try trunk.
I just kicked off the regression test suite (for trunk) on it, so that should be available in a few hours. Is it worth running it on release after that? Tom
On 18 Oct 2013 at 11:48, Tom Kent wrote:
I just kicked off the regression test suite (for trunk) on it, so that should be available in a few hours. Is it worth running it on release after that?
Once that compile fix has been committed and it compiles fully, I would say so. We'll certainly hear about it next four months if v1.55 release doesn't fully pass on VS2013 RTM. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Fri, Oct 18, 2013 at 2:51 PM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
On 18 Oct 2013 at 11:48, Tom Kent wrote:
I just kicked off the regression test suite (for trunk) on it, so that should be available in a few hours. Is it worth running it on release after that?
Once that compile fix has been committed and it compiles fully, I would say so. We'll certainly hear about it next four months if v1.55 release doesn't fully pass on VS2013 RTM.
I just noticed that the trunk tests have completed: http://www.boost.org/development/tests/trunk/developer/summary.html It's the far right column, there's a bunch of stuff failing that wasn't failing on VS2012. I'm kicking off the tests against the release branch as well, so they should be up in a few hours.
participants (13)
-
Beman Dawes -
Christian Hägele -
Domagoj Saric -
Domagoj Saric -
Frank Mori Hess -
Klaim - Joël Lamotte -
Marcel Raad -
Marshall Clow -
Niall Douglas -
Olaf van der Spek -
Peter Dimov -
Stephan T. Lavavej -
Tom Kent