[math][Sunpro] Can anyone help porting to Sun's compiler?
The new Math statistical distributions and special functions code currently fails with Sun's compiler http://beta.boost.org/development/tests/trunk/developer/output/Sandia-sun-bo... with error messages such as: "../boost/math/concepts/real_concept.hpp", line 333: Error: Could not find a match for boost::math::tools::epsilon<boost::math::tools::T>(). "../boost/math/special_functions/detail/unchecked_factorial.hpp", line 268: Error: Could not find a match for boost::math::unchecked_factorial<boost::math::RT>(unsigned). "../boost/math/special_functions/detail/unchecked_factorial.hpp", line 269: Error: Could not find a match for boost::math::unchecked_factorial<boost::math::RT>(unsigned) needed in boost::math::unchecked_factorial<boost::math::RT>(unsigned). The gcc results on that platform are pretty good, so it seems a shame not to support Sun as well, anyone have ideas? Thanks, John Maddock.
2007/10/11, John Maddock <john@johnmaddock.co.uk>:
The new Math statistical distributions and special functions code currently fails with Sun's compiler http://beta.boost.org/development/tests/trunk/developer/output/Sandia-sun-bo... with error messages such as:
"../boost/math/concepts/real_concept.hpp", line 333: Error: Could not find a match for boost::math::tools::epsilon<boost::math::tools::T>(). "../boost/math/special_functions/detail/unchecked_factorial.hpp", line 268: Error: Could not find a match for boost::math::unchecked_factorial<boost::math::RT>(unsigned). "../boost/math/special_functions/detail/unchecked_factorial.hpp", line 269: Error: Could not find a match for boost::math::unchecked_factorial<boost::math::RT>(unsigned) needed in boost::math::unchecked_factorial<boost::math::RT>(unsigned).
The gcc results on that platform are pretty good, so it seems a shame not to support Sun as well, anyone have ideas?
Probably this is a bug in Sun C++. I will take a look on it. -- Simon Atanasyan
Simon Atanasyan wrote:
The gcc results on that platform are pretty good, so it seems a shame not to support Sun as well, anyone have ideas?
Probably this is a bug in Sun C++. I will take a look on it.
Thanks Simon, if there's a workaround possible for the existing Sun releases that would be great. Regards, John
2007/10/11, John Maddock <john@johnmaddock.co.uk>:
Simon Atanasyan wrote:
The gcc results on that platform are pretty good, so it seems a shame not to support Sun as well, anyone have ideas?
Probably this is a bug in Sun C++. I will take a look on it.
Thanks Simon, if there's a workaround possible for the existing Sun releases that would be great.
Good news - the latest version of Sun C++ works good. This version of the compiler even does not need "Sun related" workaround in the boost/math/concepts/real_concept.hpp (lines 334-338). % CC -V CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25 Bad news - all other version of Sun C++ have a bug. Compiler cannot deduce a type of template parameter for the template specialization based on function return type. Here is test case for this bug: % cat test.cc template <class T> T f() { return T(); } template <> float f() { return 1.0; } int main() { f<float>(); } % CC -c test.cc "test.cc", line 9: Error: Could not find a match for f<T>(). "test.cc", line 15: Error: Could not find a match for f<T>() needed in main(). 2 Error(s) detected. A possible workaround is to add unused argument that helps compiler to handle template specialization: Following code works good: template <class T> T f(T* = 0) { return T(); } template <> float f(float*) { return 1.0; } int main() { f<float>(); } -- Simon Atanasyan
Simon Atanasyan wrote:
2007/10/11, John Maddock <john@johnmaddock.co.uk>:
Simon Atanasyan wrote:
The gcc results on that platform are pretty good, so it seems a shame not to support Sun as well, anyone have ideas?
Probably this is a bug in Sun C++. I will take a look on it.
Thanks Simon, if there's a workaround possible for the existing Sun releases that would be great.
Good news - the latest version of Sun C++ works good. This version of the compiler even does not need "Sun related" workaround in the boost/math/concepts/real_concept.hpp (lines 334-338).
Excellent.
Bad news - all other version of Sun C++ have a bug. Compiler cannot deduce a type of template parameter for the template specialization based on function return type. Here is test case for this bug:
A possible workaround is to add unused argument that helps compiler to handle template specialization: Following code works good:
template <class T> T f(T* = 0) { return T(); }
template <> float f(float*) { return 1.0; }
int main() { f<float>(); }
So this is the same issue for which we define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS and associated workarounds? If so which versions of __SUNPRO_CC should we define it for? Strangely the config tests don't pick this up: the test case is libs/config/test/boost_no_exp_func_tem_arg.ipp BTW. Thanks, John.
2007/10/12, John Maddock <john@johnmaddock.co.uk>:
Simon Atanasyan wrote:
Bad news - all other version of Sun C++ have a bug. Compiler cannot deduce a type of template parameter for the template specialization based on function return type. Here is test case for this bug:
A possible workaround is to add unused argument that helps compiler to handle template specialization: Following code works good:
template <class T> T f(T* = 0) { return T(); }
template <> float f(float*) { return 1.0; }
int main() { f<float>(); }
So this is the same issue for which we define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS and associated workarounds?
Probably yes.
If so which versions of __SUNPRO_CC should we define it for?
Unfortunately __SUNPRO_CC denotes version of compiler without patch number. This bug has been fixed since Sun C++ 5.9 patch-01. But it exists in the Sun C++ 5.9. In both cases __SUNPRO_CC is equal to 0x590.
Strangely the config tests don't pick this up: the test case is libs/config/test/boost_no_exp_func_tem_arg.ipp BTW.
boost_no_exp_func_tem_arg.ipp does not contain specialization of function template where template argument is used as a return value type only. So Sun C++ compiles this code without error. -- Simon Atanasyan
participants (2)
-
John Maddock -
Simon Atanasyan