On Wednesday, July 22, 2015 at 5:11:51 PM UTC-4, Ben Goodrich wrote:On Wednesday, July 22, 2015 at 5:08:13 PM UTC-4, Avraham Adler wrote:Any ideas why -std=gnu++0x would cause the crash it did?No, but it is also happening to me on Linux and presumably will happen once Daniel gets a chance to try on our Windows test machine. So, we can try to come up with a work around for the next StanHeaders / rstan.
Upon further review, -std=gnu++0x does not currently work with any interface to Stan if g++-4.6 is the compiler.
goodrich@T540p:/opt/stan$ git diff lib/boost_1.58.0/ | cat
diff --git a/lib/boost_1.58.0/boost/fusion/support/unused.hpp b/lib/boost_1.58.0/boost/fusion/support/unused.hpp
index 4bbe24e..08dd9ed 100644
--- a/lib/boost_1.58.0/boost/fusion/support/unused.hpp
+++ b/lib/boost_1.58.0/boost/fusion/support/unused.hpp
@@ -48,14 +48,14 @@ namespace boost { namespace fusion
{
return *this;
}
-
+/*
BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
unused_type const&
operator=(unused_type const&) const BOOST_NOEXCEPT
{
return *this;
}
-
+*/
BOOST_CXX14_CONSTEXPR BOOST_FUSION_GPU_ENABLED
unused_type&
operator=(unused_type const&) BOOST_NOEXCEPT
@@ -64,7 +64,7 @@ namespace boost { namespace fusion
}
};
- BOOST_CONSTEXPR unused_type const unused = unused_type();
+ BOOST_CONSTEXPR unused_type /*const*/ unused = unused_type();
namespace detail
{
This looks like it's related to some known issues with
the Intel compiler, where they can't handle the const version of
this operation.
goodrich@T540p:/opt/stan/lib/stan_math_2.7.0$ make stan/math/prim/arr/functor/integrate_ode.hpp-test
g++-4.6 -std=gnu++0x -I . -isystem ../../lib/eigen_3.2.4 -isystem ../../lib/boost_1.58.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -pipe -c -O0 -include sta
n/math/prim/arr/functor/integrate_ode.hpp -o /dev/null test/dummy.cpp
In file included from ../../lib/boost_1.58.0/boost/fusion/view/zip_view/zip_view.hpp:13:0,
from ../../lib/boost_1.58.0/boost/fusion/view/zip_view.hpp:12,
from ../../lib/boost_1.58.0/boost/fusion/include/zip_view.hpp:11,
from ../../lib/boost_1.58.0/boost/numeric/odeint/util/resize.hpp:26,
from ../../lib/boost_1.58.0/boost/numeric/odeint/util/state_wrapper.hpp:26,
from ../../lib/boost_1.58.0/boost/numeric/odeint/util/ublas_wrapper.hpp:33,
from ../../lib/boost_1.58.0/boost/numeric/odeint.hpp:25,
from ./stan/math/prim/arr/functor/integrate_ode.hpp:12,
from <command-line>:0:
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp: In member function ‘const boost::fusion::unused_type& boost::fusion::unused_type::operator=(const boost::fusion::unused_type&) const’:
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp:57:9: error: ‘this’ is not a potential constant expression
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp: At global scope:
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp:67:39: error: both ‘const’ and ‘constexpr’ cannot be used here
make/tests:64: recipe for target 'stan/math/prim/arr/functor/integrate_ode.hpp-test' failed
make: *** [stan/math/prim/arr/functor/integrate_ode.hpp-test] Error 1
Sebastian was telling us that the Intel compilers were related
to g++. But whatever the cause, I was just pointing out it's
the same kind of const declaration that we had to fix for
Intel.
To clarify: the intel compiler aims to produce g++ comparible binaier so that you can mix libraries compiled with either compiler. Second, you can use the intel mkl together with g++. The intel mkl provides high speed versions of linear algebra operations optimized for intel processors - it can even lay off computations on intels graphics card type processors fully automatically, this is why eigen can be compiled in mkl mode, then they switch to these operations.
Concerning the issue with the const operator and intel 14: the solution was to disable this for the intel compiler which meant to ifdef this stuff out of the boost headers and in addition bob programmed around it. Just have a look at the not-in-bh extra includes which you have in rstan to override the original boost bh includes.
Hope that helps.
Sebastian
... Code you even get the jacobian and hessian...
Concerning the issue with the const operator and intel 14: the solution was to disable this for the intel compiler which meant to ifdef this stuff out of the boost headers and in addition bob programmed around it. Just have a look at the not-in-bh extra includes which you have in rstan to override the original boost bh includes.
BOOST_CONSTEXPR unused_type const unused = unused_type();
As Rtools development for 4.9.x is all but stopped (Kevin Ushey has someone working on it, but it's not anywhere near completion last I checked), those of us who use R/Stan/rstan on windows would appreciate any fixes. For the time being, as long as Makevars doesn't pass -gnu++0x or -c++0x, it will work, so it should be lower priority than true bugs, IMHO.
Thanks!
Avi