3 important Intel regressions and some other stuff
The following regressions seem to be special to Intel 8: - numeric/uBLAS The only way to solve this seems at the moment not to use the "Multithreaded Debug DLL" runtime. When we can isolate the problem, Intel should investigate. - Python The slice test case is failing! Any ideas? - random error: no operator "<<" matches these operands I've not heard any comment in the last days about that. Any ideas? Aleksey, could we have a link to http://boost.sourceforge.net/regression-logs/developer/python.html on the boost regression site? I can't find any link to this page anywhere. I'm now going to leave now and I'll return on Sunday. I don't know if I can manage to get the regressions being run automatically, otherwise you get the next results for Intel 8 + CW 9 on Sunday. Stefan
Stefan Slapeta <stefan_nospam_@slapeta.com> writes:
- Python The slice test case is failing! Any ideas?
Are you looking at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/python.html Looks very unhealthy to me! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
Stefan Slapeta <stefan_nospam_@slapeta.com> writes:
- Python The slice test case is failing! Any ideas?
Are you looking at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/python.html
Looks very unhealthy to me!
Indeed. Do you plan to look into it? If not, I'd appreciate if you marked Boost.Python as unusable with this toolset. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Are you looking at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/python.ht ml
Looks very unhealthy to me!
Indeed. Do you plan to look into it? If not, I'd appreciate if you marked Boost.Python as unusable with this toolset.
At the moment, *all* tests fail with 3.4 due to some error in build system or configuration. - Volodya
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
Stefan Slapeta <stefan_nospam_@slapeta.com> writes:
- Python The slice test case is failing! Any ideas?
Are you looking at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/python.html
Looks very unhealthy to me!
Indeed. Do you plan to look into it? If not, I'd appreciate if you marked Boost.Python as unusable with this toolset.
I did plan to look at it on my vacation, but it appears my Linux machine is unreachable via ssh from the outside for some reason :(. I have serious doubts that the library is actually unusable with Intel 8/Linux though. It looks like the library is failing to build, perhaps due to a config problem at the test site. I can't tell, though, because the new test reports don't seem to show library build failures. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Indeed. Do you plan to look into it? If not, I'd appreciate if you marked Boost.Python as unusable with this toolset.
I did plan to look at it on my vacation, but it appears my Linux machine is unreachable via ssh from the outside for some reason :(.
I have serious doubts that the library is actually unusable with Intel 8/Linux though. It looks like the library is failing to build, perhaps due to a config problem at the test site. I can't tell, though, because the new test reports don't seem to show library build failures.
Martin, are you aware that if Python is built with Intel C++, you need to use "<stdlib>default" in your BUILD selection? Aleksey, can you do something to arrange that when a library needed by a test fails to build, the output is browsable through the regression log? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Martin, are you aware that if Python is built with Intel C++, you need to use "<stdlib>default" in your BUILD selection?
The tests are currently being run against a Python built with gcc. I seem to recall you asked me to switch back to that. So, to clarify: which Python binaries should I run the tests against for which version of icc? Regards, m
Martin Wille <mw8329@yahoo.com.au> writes:
David Abrahams wrote:
Martin, are you aware that if Python is built with Intel C++, you need to use "<stdlib>default" in your BUILD selection?
The tests are currently being run against a Python built with gcc. I seem to recall you asked me to switch back to that.
So, to clarify: which Python binaries should I run the tests against for which version of icc?
Here's what (I think) I know: Intel C++ 8.0 has a cxxlib command-line option. If you set it to gcc, it *should* work with a GCC-compiled Python. According to my reading of the code, that is the default for Boost.Build when building Boost.Python and its tests. If you use this option with an ICC-compiled Python, it will fail. Intel C++ 7.1 produces internal compiler errors when used with -cxxlib-gcc, therefore, you have to use <stdlib>default to turn off the use of -cxxlib-gcc, and you have to use an ICC-compiled Python. HTH, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Martin Wille <mw8329@yahoo.com.au> writes:
David Abrahams wrote:
Martin, are you aware that if Python is built with Intel C++, you need to use "<stdlib>default" in your BUILD selection?
The tests are currently being run against a Python built with gcc. I seem to recall you asked me to switch back to that.
So, to clarify: which Python binaries should I run the tests against for which version of icc?
Here's what (I think) I know:
Intel C++ 8.0 has a cxxlib command-line option. If you set it to gcc, it *should* work with a GCC-compiled Python. According to my reading of the code, that is the default for Boost.Build when building Boost.Python and its tests. If you use this option with an ICC-compiled Python, it will fail.
That's my understanding, too.
Intel C++ 7.1 produces internal compiler errors when used with -cxxlib-gcc, therefore, you have to use <stdlib>default to turn off the use of -cxxlib-gcc, and you have to use an ICC-compiled Python.
This surprises me. I thought icc 7 doesn't have the exception- handling issues with shared libraries from gcc. Anyway, I'll add another toolset to the tests I run. Regards, m
Martin Wille <mw8329@yahoo.com.au> writes:
This surprises me. I thought icc 7 doesn't have the exception- handling issues with shared libraries from gcc.
According to my tests, it does.
Anyway, I'll add another toolset to the tests I run.
How will that help? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Martin Wille <mw8329@yahoo.com.au> writes:
This surprises me. I thought icc 7 doesn't have the exception- handling issues with shared libraries from gcc.
According to my tests, it does.
Anyway, I'll add another toolset to the tests I run.
How will that help?
FWIW, also, all the Boost.Python tests are passing for me using Intel8/linux. I am just using a toolset file that contains: { local INTEL_LINUX_VERSION = 80 ; extends-toolset intel-linux ; } Also, on Intel7/linux the only problems I see have to do with exception-handling, which I assume is caused by not using an icc-compiled Python binary. That looks nothing like the problems you're seeing (e.g. http://tinyurl.com/5p6eu) which seem to indicate not only that the build system is not functioning properly (the -v option is being added to test command-lines after python instead of after the .py script being tested) and that none of the extension modules can be loaded due to the missing symbol std::_BADOFF. I'm not seeing any of these symptoms either. My intel7 toolset is, naturally: { local INTEL_LINUX_VERSION = 70 ; extends-toolset intel-linux ; } -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
How will that help?
FWIW, also, all the Boost.Python tests are passing for me using Intel8/linux.
Correction: all but the embedding test are passing. I can't figure out why, but the linker seems to fail to find symbols from the <ctype.h> header no matter whether I use the intel or GCC cxxlib. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Martin Wille <mw8329@yahoo.com.au> writes:
This surprises me. I thought icc 7 doesn't have the exception- handling issues with shared libraries from gcc.
According to my tests, it does.
ACK
Anyway, I'll add another toolset to the tests I run.
How will that help?
This will be a second intel-7.1 toolset which will use an intel-built copy of Python and <stdlib>default. Regards, m
David Abrahams writes:
Aleksey, can you do something to arrange that when a library needed by a test fails to build, the output is browsable through the regression log?
Usually that's already the case (see, for instance, http://tinyurl.com/3lvg9), but obviously, for some reason, Boost.Python is not handled properly. Put on the short-term TODO list. -- Aleksey Gurtovoy MetaCommunications Engineering
David Abrahams wrote:
Stefan Slapeta <stefan_nospam_@slapeta.com> writes:
- Python The slice test case is failing! Any ideas?
Are you looking at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/python.html
Looks very unhealthy to me!
What I _really_ meant was win32 which was failing but now seems to be ok again. Stefan
Stefan Slapeta wrote:
Aleksey, could we have a link to http://boost.sourceforge.net/regression-logs/developer/python.html on the boost regression site? I can't find any link to this page anywhere.
Sorry, copy-paste issue. What I meant was: http://boost.sourceforge.net/regression-logs/developer (now redirects to metacomm) Why is there no link to it on the boost page? Stefan
Stefan Slapeta writes:
Stefan Slapeta wrote:
Aleksey, could we have a link to http://boost.sourceforge.net/regression-logs/developer/python.html on the boost regression site? I can't find any link to this page anywhere.
Sorry, copy-paste issue. What I meant was:
http://boost.sourceforge.net/regression-logs/developer (now redirects to metacomm)
Why is there no link to it on the boost page?
There is now, see the top of http://boost.sourceforge.net/regression-logs/ -- Aleksey Gurtovoy MetaCommunications Engineering
participants (2)
-
Aleksey Gurtovoy -
David Abrahams -
Martin Wille -
Stefan Slapeta -
Vladimir Prus