[bind] bind_visit_test failure on GCC 4.1.0 and HP/CXX
The test fails with the following message: bind_visit_test.cpp(61): test 'vis.hash == 34' failed in function 'int main()' It has been failing on HP/CXX only for quite some time, but now I noted it also fails on GCC 4.1.0 Linux and Tru64. Is this an issue with the test? Markus
Markus Schöpflin wrote:
The test fails with the following message:
bind_visit_test.cpp(61): test 'vis.hash == 34' failed in function 'int main()'
It has been failing on HP/CXX only for quite some time, but now I noted it also fails on GCC 4.1.0 Linux and Tru64. Is this an issue with the test?
The test has to result in one of the following sequences: vis( f ); vis( 3 ); vis( _1 ); vis( 4 ); or vis( f ); vis( 3 ); vis( 4 ); so vis.hash needs to be 34 afterwards. If it isn't, the visitor isn't being called, and boost::signal automatic disconnect will probably not work.
Peter Dimov wrote:
Markus Schöpflin wrote:
The test fails with the following message:
bind_visit_test.cpp(61): test 'vis.hash == 34' failed in function 'int main()'
It has been failing on HP/CXX only for quite some time, but now I noted it also fails on GCC 4.1.0 Linux and Tru64. Is this an issue with the test?
The test has to result in one of the following sequences:
vis( f ); vis( 3 ); vis( _1 ); vis( 4 );
or
vis( f ); vis( 3 ); vis( 4 );
so vis.hash needs to be 34 afterwards. If it isn't, the visitor isn't being called, and boost::signal automatic disconnect will probably not work.
IOW, you're 100% sure that both compilers somehow get this wrong when the test fails. Markus
Markus Schöpflin wrote:
IOW, you're 100% sure that both compilers somehow get this wrong when the test fails.
Can you try this modification (also in CVS HEAD) that would tell us more about what's going on: --- bind_visit_test.cpp 28 Feb 2006 21:36:42 -0000 1.1 +++ bind_visit_test.cpp 21 Apr 2006 11:51:50 -0000 @@ -22,6 +22,7 @@ #endif #include <iostream> +#include <typeinfo> #if defined(BOOST_MSVC) && (BOOST_MSVC < 1300) # pragma warning(pop) @@ -37,12 +38,14 @@ { } - template<typename T> void operator()( T const & /*t*/ ) + template<typename T> void operator()( T const & t ) { + std::cout << "visitor::operator()( T ): " << typeid( t ).name() << std::endl; } void operator()( int const & t ) { + std::cout << "visitor::operator()( int ): " << t << std::endl; hash = hash * 10 + t; } };
Peter Dimov wrote:
Can you try this modification (also in CVS HEAD) that would tell us more about what's going on:
Here are the results for gcc 4.1.0 on Linux and Tru64: visitor::operator()( T ): PFiiiiE visitor::operator()( T ): N5boost3_bi5valueIiEE visitor::operator()( T ): N5boost3_bi5valueIiEE bind_visit_test.cpp(64): test 'vis.hash == 34' failed in function 'int main()' 1 error detected. And here is the result for cxx on Tru64: visitor::operator()( T ): int (*)(int, int, int) visitor::operator()( T ): boost::_bi::value<int> visitor::operator()( T ): boost::_bi::value<int> bind_visit_test.cpp(64): test 'vis.hash == 34' failed in function '(unknown)' 1 error detected. HTH, Markus
Markus Schöpflin wrote:
Peter Dimov wrote:
Can you try this modification (also in CVS HEAD) that would tell us more about what's going on:
Here are the results for gcc 4.1.0 on Linux and Tru64:
visitor::operator()( T ): PFiiiiE visitor::operator()( T ): N5boost3_bi5valueIiEE visitor::operator()( T ): N5boost3_bi5valueIiEE bind_visit_test.cpp(64): test 'vis.hash == 34' failed in function 'int main()' 1 error detected.
And here is the result for cxx on Tru64:
visitor::operator()( T ): int (*)(int, int, int) visitor::operator()( T ): boost::_bi::value<int> visitor::operator()( T ): boost::_bi::value<int> bind_visit_test.cpp(64): test 'vis.hash == 34' failed in function '(unknown)' 1 error detected.
HTH, Markus
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
As it's a bug fix it should be merged IMO. But it's on the release manager to decide, of course. Thanks, Markus
Markus Schöpflin wrote:
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
As it's a bug fix it should be merged IMO. But it's on the release manager to decide, of course.
Could the review manager please comment on this? Thanks, Markus
Markus Schöpflin wrote:
Markus Schöpflin wrote:
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things. As it's a bug fix it should be merged IMO. But it's on the release manager to decide, of course.
Could the review manager please comment on this?
Please go ahead and merge it. Thomas -- Thomas Witt witt@acm.org
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
Oh, and I forgot to mention that I can confirm that it now passes for both GCC 4.1.0 and CXX 7.1-006 on Tru64. Markus
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
Why does that bug get detected only on 64bit platforms? The bind tests pass for gcc 4.1.0 an Linux-x86. Shouldn't a two-phase lookup problem manifest itself on all platforms supported by gcc 4.1.0? Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille wrote:
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
Why does that bug get detected only on 64bit platforms? The bind tests pass for gcc 4.1.0 an Linux-x86. Shouldn't a two-phase lookup problem manifest itself on all platforms supported by gcc 4.1.0?
I see the same failure in http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output/...
Peter Dimov wrote:
Martin Wille wrote:
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
Why does that bug get detected only on 64bit platforms? The bind tests pass for gcc 4.1.0 an Linux-x86. Shouldn't a two-phase lookup problem manifest itself on all platforms supported by gcc 4.1.0?
I see the same failure in
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output/...
hmm, in the RC, I see the failures only in x86_64. Perhaps, I confused the errors. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille wrote:
Peter Dimov wrote:
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
Why does that bug get detected only on 64bit platforms? The bind tests pass for gcc 4.1.0 an Linux-x86. Shouldn't a two-phase lookup problem manifest itself on all platforms supported by gcc 4.1.0?
It failed for me on 32 bit linux and 64 bit alpha with gcc 4.1.0 on both HEAD and the RC branch. Markus
From tests results on metacomm web site, it seems to me, that some platforms are using Boost.Build v1 while others are using v2.
For being certified as a supported compiler in 1.34 release, is it a requirement to use Boost.Build v2? Thanks, Boris Gubenko
Boris Gubenko wrote:
From tests results on metacomm web site, it seems to me, that some platforms are using Boost.Build v1 while others are using v2.
For being certified as a supported compiler in 1.34 release, is it a requirement to use Boost.Build v2?
The plan is to use V2 for 1.34, but I have no idea if it's a requirement. Both HP CXX versions under test already use V2. Markus
Boris Gubenko wrote:
From tests results on metacomm web site, it seems to me, that some platforms are using Boost.Build v1 while others are using v2.
For being certified as a supported compiler in 1.34 release, is it a requirement to use Boost.Build v2?
That is the current plan. Thomas Release Manager -- Thomas Witt witt@acm.org
Thomas Witt ha escrito:
Boris Gubenko wrote:
From tests results on metacomm web site, it seems to me, that some platforms are using Boost.Build v1 while others are using v2.
For being certified as a supported compiler in 1.34 release, is it a requirement to use Boost.Build v2?
That is the current plan.
Thomas
Release Manager
Hello Thomas, regarding the release procedure, is there any tentative scheduling, or are we stuck due to SF CVS outage or any other external factor? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Thomas Witt ha escrito:
Boris Gubenko wrote:
From tests results on metacomm web site, it seems to me, that some platforms are using Boost.Build v1 while others are using v2.
For being certified as a supported compiler in 1.34 release, is it a requirement to use Boost.Build v2? That is the current plan.
Thomas
Release Manager
Hello Thomas, regarding the release procedure, is there any tentative scheduling, or are we stuck due to SF CVS outage or any other external factor?
I'd also like to know what the release schedule is. I need to do another bjam release for BBv2 to work out of the box when the release happens before then, and I want to know if I need to do it in the next 2 days before a vacation. Or if I can do it after the vacation a week and a half later :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera <grafik.list@redshift-software.com> writes:
Joaquín Mª López Muñoz wrote:
Thomas Witt ha escrito:
Boris Gubenko wrote:
From tests results on metacomm web site, it seems to me, that some platforms are using Boost.Build v1 while others are using v2.
For being certified as a supported compiler in 1.34 release, is it a requirement to use Boost.Build v2? That is the current plan.
Thomas
Release Manager
Hello Thomas, regarding the release procedure, is there any tentative scheduling, or are we stuck due to SF CVS outage or any other external factor?
I'd also like to know what the release schedule is. I need to do another bjam release for BBv2 to work out of the box when the release happens before then, and I want to know if I need to do it in the next 2 days before a vacation. Or if I can do it after the vacation a week and a half later :-)
I'm guessing we'll need that week and a half to finish the documentation updates for the Parameter library and Boost.Python. :( -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes: I'm guessing we'll need that week and a half to finish the documentation updates for the Parameter library and Boost.Python. :(
And to work through regressions. Thomas PS: Enjoy your vacation. -- Thomas Witt witt@acm.org
Peter Dimov wrote:
Markus Schöpflin wrote:
Peter Dimov wrote:
Can you try this modification (also in CVS HEAD) that would tell us more about what's going on: Here are the results for gcc 4.1.0 on Linux and Tru64:
visitor::operator()( T ): PFiiiiE visitor::operator()( T ): N5boost3_bi5valueIiEE visitor::operator()( T ): N5boost3_bi5valueIiEE bind_visit_test.cpp(64): test 'vis.hash == 34' failed in function 'int main()' 1 error detected.
And here is the result for cxx on Tru64:
visitor::operator()( T ): int (*)(int, int, int) visitor::operator()( T ): boost::_bi::value<int> visitor::operator()( T ): boost::_bi::value<int> bind_visit_test.cpp(64): test 'vis.hash == 34' failed in function '(unknown)' 1 error detected.
HTH, Markus
It does, thanks. This is a bug in boost::bind that is exposed by two-phase lookup. I fixed it in CVS HEAD. Not sure yet what to do with the 1.34 branch as changes in boost::bind have a potential to break other things.
Great, this seems to have fixed a long standing problem with the signals library as well which previously has been rated as a compiler bug. :-) And thanks for the merge. Markus
participants (8)
-
Boris Gubenko -
David Abrahams -
Joaquín Mª López Muñoz -
Markus Schöpflin -
Martin Wille -
Peter Dimov -
Rene Rivera -
Thomas Witt