Intel Compiler 11 and Boost 1.39 Bessel functions
Hi, I've tried this code with Boost 1.39 (1.37 has the same behavior) and icpc 11.0.083: #include <iostream> #include <boost/math/special_functions/bessel.hpp> int main(int argv, char** argc) { std::cout << boost::math::cyl_bessel_i(0, 0) << std::endl; } With -g -03, this crashes with an internal error. The issue was reported to Intel (but if you have a solution, I'm all ears). Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
I've tried this code with Boost 1.39 (1.37 has the same behavior) and icpc 11.0.083:
#include <iostream> #include <boost/math/special_functions/bessel.hpp>
int main(int argv, char** argc) { std::cout << boost::math::cyl_bessel_i(0, 0) << std::endl; }
With -g -03, this crashes with an internal error. The issue was reported to Intel (but if you have a solution, I'm all ears).
If it's an internal compiler error then frankly your guess is as good as mine :-( I can't reproduce here with Intel-11 on Windows and my Intel-Linux license has just expired so I can't reproduce there either :-( If you can narrow down the code that causes the compiler to choke I might be able to suggest some alternatives though, Sorry I can't be more helpful, John.
2009/7/20 John Maddock <john@johnmaddock.co.uk>:
I've tried this code with Boost 1.39 (1.37 has the same behavior) and icpc 11.0.083:
#include <iostream> #include <boost/math/special_functions/bessel.hpp>
int main(int argv, char** argc) { std::cout << boost::math::cyl_bessel_i(0, 0) << std::endl; }
With -g -03, this crashes with an internal error. The issue was reported to Intel (but if you have a solution, I'm all ears).
If it's an internal compiler error then frankly your guess is as good as mine :-(
I can't reproduce here with Intel-11 on Windows and my Intel-Linux license has just expired so I can't reproduce there either :-(
:| Perhaps you can try the free non-commercial edition?
If you can narrow down the code that causes the compiler to choke I might be able to suggest some alternatives though,
I've narrowed the problem down to two lines in bessel.hpp: - the call to bessel_ik() line 262 - the recursive call to cyl_bessel_imp() Commenting both of them makes the error disappear. If one of these lines is compiled, the compiler crashes (don't know why a recursive call can do that :|)
Sorry I can't be more helpful, John.
No worries, as you've said, it is mainly a compiler issue! Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
If you can narrow down the code that causes the compiler to choke I might be able to suggest some alternatives though,
I've narrowed the problem down to two lines in bessel.hpp: - the call to bessel_ik() line 262 - the recursive call to cyl_bessel_imp() Commenting both of them makes the error disappear. If one of these lines is compiled, the compiler crashes (don't know why a recursive call can do that :|) ~~~~~~~~~~~~~~~~~~ Weird, what happens if you compile with -O3 but not -g ? John.
2009/7/20 John Maddock <john@johnmaddock.co.uk>:
If you can narrow down the code that causes the compiler to choke I might be able to suggest some alternatives though,
I've narrowed the problem down to two lines in bessel.hpp: - the call to bessel_ik() line 262 - the recursive call to cyl_bessel_imp()
Commenting both of them makes the error disappear. If one of these lines is compiled, the compiler crashes (don't know why a recursive call can do that :|)
~~~~~~~~~~~~~~~~~~
Weird, what happens if you compile with -O3 but not -g ?
It works like a charm. You have to put those two flags to raise the internal error (we use -g to have a least some kind of feedback for optimized code) Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
Weird, what happens if you compile with -O3 but not -g ?
It works like a charm. You have to put those two flags to raise the internal error (we use -g to have a least some kind of feedback for optimized code)
Could you isolate the bessel function usage to a single file and compile that one file without -g? Sorry, it's all I can think of at present :-( John.
Could you isolate the bessel function usage to a single file and compile that one file without -g?
You mean with -P to create a simple preprocessed file ? I can do, yes. Without -g, it will pass (I've tried this on my real case before I found the guilty function).
Sorry, it's all I can think of at present :-(
No problem. I tried to dig inside the details functions, but they are too complicated for the scarce amount of time I have for this :( (I'll let Intel find a solution :D) Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
Could you isolate the bessel function usage to a single file and compile that one file without -g?
You mean with -P to create a simple preprocessed file ? I can do, yes. Without -g, it will pass (I've tried this on my real case before I found the guilty function).
No I mean use separate file compilation, so you build everything with -g *except* that problem function.
Sorry, it's all I can think of at present :-(
No problem. I tried to dig inside the details functions, but they are too complicated for the scarce amount of time I have for this :( (I'll let Intel find a solution :D)
Me too I think: I have now been able to reproduce on Linux, but the small amount of playing around I gave it failed to find a workaround :-( John.
2009/7/21 John Maddock <john@johnmaddock.co.uk>:
Could you isolate the bessel function usage to a single file and compile that one file without -g?
You mean with -P to create a simple preprocessed file ? I can do, yes. Without -g, it will pass (I've tried this on my real case before I found the guilty function).
No I mean use separate file compilation, so you build everything with -g *except* that problem function.
Oh ! Yes, it would be possible, but it would add some complexity to my SCons file, so I'll probably try without -g until Intel releases a fixed compiler.
Sorry, it's all I can think of at present :-(
No problem. I tried to dig inside the details functions, but they are too complicated for the scarce amount of time I have for this :( (I'll let Intel find a solution :D)
Me too I think: I have now been able to reproduce on Linux, but the small amount of playing around I gave it failed to find a workaround :-(
Well, at least, you confirmed that the problem is not in the chair in front of my computer! Thanks a lot for your time. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
We got this error too, I brought it up in a debugger and it occurs in the EDG frontend, which is used by quite a number of companies. If i'm correct, this'll also affect Como and SGI toolchains (maybe others). Good find, anyway :)
According to Intel, 11.1 should work. I don't have the timle to test it right away, but it is good news! Matthieu 2009/7/21 McLemon, Sean <Sean.McLemon@analog.com>:
We got this error too, I brought it up in a debugger and it occurs in the EDG frontend, which is used by quite a number of companies. If i'm correct, this'll also affect Como and SGI toolchains (maybe others). Good find, anyway :) _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher
participants (4)
-
John Maddock -
Matthieu Brucher -
McLemon, Sean