Regression results for Intel 8 online
I've put them here: http://genericprogramming.com/boost Failures: - ublas (2) - test (_many_)!! - thread/test_read_write_mutex like on other compilers - random(2) - date_time/testmicrosec_time_clock -> should be expected??? Furthermore some in range and serialization. Spirit is missing somehow; were the tests not included when the source was moved to boost CVS? Stefan
Gennadiy Rozental wrote:
Failures: - test (_many_)!!
None of them seems to be valid ifstream_iterator test fails because it couldn't locate pattern file. Why?
I don't know - where should I find this file?
The rest are supposed to fail at runtime. And they did. Why failure?
No idea. Stefan
I've put them here: http://genericprogramming.com/boost
Failures: - ublas (2) - test (_many_)!! - thread/test_read_write_mutex like on other compilers - random(2) - date_time/testmicrosec_time_clock -> should be expected???
Furthermore some in range and serialization.
That's not too good, the last release had a 100% pass rate for Intel, this one really should as well unless there are some really good reasons... John.
On Tue, 20 Jul 2004 11:22:01 +0100, John Maddock wrote
I've put them here: http://genericprogramming.com/boost
Failures: - ublas (2) - test (_many_)!! - thread/test_read_write_mutex like on other compilers - random(2) - date_time/testmicrosec_time_clock -> should be expected???
This one is expected. It only passed in 1.32 because we were incorrectly reporting the result as passing.
Furthermore some in range and serialization.
That's not too good, the last release had a 100% pass rate for Intel, this one really should as well unless there are some really good reasons...
Agreed... Jeff
John Maddock wrote:
I've put them here: http://genericprogramming.com/boost
Failures: - ublas (2) - test (_many_)!! - thread/test_read_write_mutex like on other compilers - random(2) - date_time/testmicrosec_time_clock -> should be expected???
Furthermore some in range and serialization.
That's not too good, the last release had a 100% pass rate for Intel, this one really should as well unless there are some really good reasons...
The read_write_mutex is new, so it's not a true regression from the previous 100% pass rate. I'm currently working on the scheduling algorithm to make it pass its unit tests and hopefully deal with reported deadlocking issues. Mike
Michael Glassford wrote:
John Maddock wrote:
I've put them here: http://genericprogramming.com/boost
Failures: - ublas (2) - test (_many_)!! - thread/test_read_write_mutex like on other compilers - random(2) - date_time/testmicrosec_time_clock -> should be expected???
Furthermore some in range and serialization.
That's not too good, the last release had a 100% pass rate for Intel, this one really should as well unless there are some really good reasons...
The read_write_mutex is new, so it's not a true regression from the previous 100% pass rate. I'm currently working on the scheduling algorithm to make it pass its unit tests and hopefully deal with reported deadlocking issues.
Please, fix that quickly. Someone fixed the cause of the compile errors for the more conforming compilers. So, now, I can expect the tests to deadlock for every compiler. This is a showstopper for testing, IMHO. I'm considering to remove the test from the Jamfile until the problem has been fixed. Regards, m
Martin Wille wrote:
Michael Glassford wrote:
[snip report of failures in various libraries]
The read_write_mutex is new, so it's not a true regression from the previous 100% pass rate. I'm currently working on the scheduling algorithm to make it pass its unit tests and hopefully deal with reported deadlocking issues.
Please, fix that quickly.
Believe me, I've been trying.
Someone fixed the cause of the compile errors for the more conforming compilers.
I fixed many compile errors, and had help with a couple of others.
So, now, I can expect the tests to deadlock for every compiler. This is a showstopper for testing, IMHO. I'm considering to remove the test from the Jamfile until the problem has been fixed.
I've just checked in the changes that I've been working on. I can't guarantee that they fix the deadlocks until they're tested on the platforms that were experiencing problems, but I hope they do. I'll keep an eye on the regression testing reports, but please let me know one way or the other as soon as you find out anything. Thanks, Mike
The regressions are finished and should appear in the metacomm result tables after the next update there. Can anybody give me a hint how to configure the test for Intel + STLPort? Is it sufficient to add the include+lib paths? Stefan
Stefan Slapeta <stefan_nospam_@slapeta.com> writes:
The regressions are finished and should appear in the metacomm result tables after the next update there.
Can anybody give me a hint how to configure the test for Intel + STLPort? Is it sufficient to add the include+lib paths?
Just follow the configuration instructions for the intel-win32-stlport toolset, I assume. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Just follow the configuration instructions for the intel-win32-stlport toolset, I assume.
This was confusing me. There is no such configuration documented here: http://www.boost.org/more/getting_started.html#step3 Stefan
Stefan Slapeta <stefan_nospam_@slapeta.com> writes:
David Abrahams wrote:
Just follow the configuration instructions for the intel-win32-stlport toolset, I assume.
This was confusing me. There is no such configuration documented here:
Oh. I don't know what to tell you then. It was checked in by Beman. I actually have a modified copy on my disk (enclosed). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Oh. I don't know what to tell you then. It was checked in by Beman. I actually have a modified copy on my disk (enclosed).
Thanks. Another problem: the link to the cw-tools page is broken on http://www.boost.org/more/getting_started.html#step3 (--> http://www.boost.org/tools/build/v1/cw-tools.html) Stefan
Stefan Slapeta wrote:
Thanks. Another problem: the link to the cw-tools page is broken on
That's because that toolset got added after 1.31, which is the version on the boost site. But the getting started page got updated to fix references about cvs.boost.sf.net. The docs are in CVS and will be there when the 1.32 release happens. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Stefan Slapeta writes:
The regressions are finished and should appear in the metacomm result tables after the next update there.
Stefan, It seems that the logs didn't get uploaded. Could you please run the attached 'regression.py' with the 'upload' command, e.g. python regression.py upload --runner=<your runner id> ?
Can anybody give me a hint how to configure the test for Intel + STLPort? Is it sufficient to add the include+lib paths?
The right way to start would be to copy/rename "intel-win32-7.1-vc6-stlport-4.5.3-tools.jam" toolset, and set the the same variables as in http://www.boost.org/tools/build/v1/vc7-stlport-tools.html. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (9)
-
Aleksey Gurtovoy -
David Abrahams -
Gennadiy Rozental -
Jeff Garland -
John Maddock -
Martin Wille -
Michael Glassford -
Rene Rivera -
Stefan Slapeta