I've been looking at some of the remaining regressions, and I have a fix for the issue here: http://tinyurl.com/yq6a5o I'm a little bit dubious about this patch, because I don't believe the fix should be necessary in the first place (can't understand why the compiler's complaining in the first place!), however it does fix the issue and appears harmless for the msvc/intel/gcc/borland compilers I've tested with. OK to go ahead and apply? John. ? out.txt Index: common_factor_test.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/math/test/common_factor_test.cpp,v retrieving revision 1.9 diff -u -r1.9 common_factor_test.cpp --- common_factor_test.cpp 4 Dec 2006 07:04:33 -0000 1.9 +++ common_factor_test.cpp 16 Feb 2007 16:39:48 -0000 @@ -163,7 +163,7 @@ BOOST_STATIC_CONSTANT(bool, has_infinity = limits_type::has_infinity); BOOST_STATIC_CONSTANT(bool, has_quiet_NaN = limits_type::has_quiet_NaN); BOOST_STATIC_CONSTANT(bool, has_signaling_NaN = limits_type::has_signaling_NaN); - BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = limits_type::has_denorm); + BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = (float_denorm_style)limits_type::has_denorm); BOOST_STATIC_CONSTANT(bool, has_denorm_loss = limits_type::has_denorm_loss); static MyInt1 infinity() throw() { return limits_type::infinity(); } @@ -177,7 +177,7 @@ BOOST_STATIC_CONSTANT(bool, traps = limits_type::traps); BOOST_STATIC_CONSTANT(bool, tinyness_before = limits_type::tinyness_before); - BOOST_STATIC_CONSTANT(float_round_style, round_style = limits_type::round_style); + BOOST_STATIC_CONSTANT(float_round_style, round_style = (float_round_style)limits_type::round_style); }; // std::numeric_limits<MyInt1> @@ -210,7 +210,7 @@ BOOST_STATIC_CONSTANT(bool, has_infinity = limits_type::has_infinity); BOOST_STATIC_CONSTANT(bool, has_quiet_NaN = limits_type::has_quiet_NaN); BOOST_STATIC_CONSTANT(bool, has_signaling_NaN = limits_type::has_signaling_NaN); - BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = limits_type::has_denorm); + BOOST_STATIC_CONSTANT(float_denorm_style, has_denorm = (float_denorm_style)limits_type::has_denorm); BOOST_STATIC_CONSTANT(bool, has_denorm_loss = limits_type::has_denorm_loss); static MyUnsigned1 infinity() throw() { return limits_type::infinity(); } @@ -225,7 +225,7 @@ BOOST_STATIC_CONSTANT(bool, traps = limits_type::traps); BOOST_STATIC_CONSTANT(bool, tinyness_before = limits_type::tinyness_before); - BOOST_STATIC_CONSTANT(float_round_style, round_style = limits_type::round_style); + BOOST_STATIC_CONSTANT(float_round_style, round_style = (float_round_style)limits_type::round_style); }; // std::numeric_limits<MyUnsigned1>
John Maddock wrote:
I'm a little bit dubious about this patch, because I don't believe the fix should be necessary in the first place (can't understand why the compiler's complaining in the first place!) Here's the error message: error C2440: 'initializing' : cannot convert from '' to 'const _STL::float_denorm_style'
Given that the source type is empty, this sounds like a compiler bug. Sebastian Redl
John Maddock wrote:
I've been looking at some of the remaining regressions, and I have a fix for the issue here: http://tinyurl.com/yq6a5o
I'm a little bit dubious about this patch, because I don't believe the fix should be necessary in the first place (can't understand why the compiler's complaining in the first place!), however it does fix the issue and appears harmless for the msvc/intel/gcc/borland compilers I've tested with. OK to go ahead and apply?
It's dubious indeed. All I can say that it seems very unlikely that the problem is on our side of the fence. So I think it's the right thing to do. Please commit. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
John Maddock wrote:
I've been looking at some of the remaining regressions, and I have a fix for the issue here: http://tinyurl.com/yq6a5o
I'm a little bit dubious about this patch, because I don't believe the fix should be necessary in the first place (can't understand why the compiler's complaining in the first place!), however it does fix the issue and appears harmless for the msvc/intel/gcc/borland compilers I've tested with. OK to go ahead and apply?
It's dubious indeed. All I can say that it seems very unlikely that the problem is on our side of the fence. So I think it's the right thing to do.
Please commit.
Done, if there are any regressions, I'll just back it out and mark up the test instead. John.
John Maddock wrote:
It's dubious indeed. All I can say that it seems very unlikely that the problem is on our side of the fence. So I think it's the right thing to do.
Please commit.
Done, if there are any regressions, I'll just back it out and mark up the test instead.
There were regressions, change backed out :-( John.
participants (3)
-
John Maddock -
Sebastian Redl -
Thomas Witt