[math] fpclassify.hpp fails to compile with Intel icc 11.1
Hi all, The following code fails to compile with icc 11.1 under Linux: ========== #include <boost/math/special_functions/fpclassify.hpp> int main() {} ========== The full error is: ========== /usr/include/c++/4.4.5/cmath(500): error: identifier "__builtin_fpclassify" is undefined return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, ^ detected during: instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::fpclassify(_Tp) [with _Tp=long double]" at line 104 of "/usr/include/boost/math/special_functions/fpclassify.hpp" instantiation of "bool boost::math_detail::is_nan_helper(T, const boost::true_type &) [with T=long double]" at line 137 of "/usr/include/boost/math/special_functions/fpclassify.hpp" instantiation of "int boost::math::detail::fpclassify_imp(T, const boost::math::detail::generic_tag<true> &) [with T=long double]" at line 242 of "/usr/include/boost/math/special_functions/fpclassify.hpp" compilation aborted for main.cpp (code 2) ========== The same code compiles fine under icc 12.0. I also tried explicitly adding: #define BOOST_MATH_DISABLE_STD_FPCLASSIFY before including the header, but got the same error. The math library docs say that icc 10.0 and later are fully supported with no serious caveats, so I presume this is a bug. Should I file a ticket? Please let me know if there is any other information about my system which could be useful to know. Thanks, -Gabe
Further experiments show that the issue is present in boost 1.42, but fixed in boost 1.45. Sorry for the noise :) Thanks, -Gabe On Mon, Jan 3, 2011 at 11:53 AM, Gabriel Redner <gredner@gmail.com> wrote:
Hi all,
The following code fails to compile with icc 11.1 under Linux:
========== #include <boost/math/special_functions/fpclassify.hpp> int main() {} ==========
The full error is:
========== /usr/include/c++/4.4.5/cmath(500): error: identifier "__builtin_fpclassify" is undefined return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, ^ detected during: instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::fpclassify(_Tp) [with _Tp=long double]" at line 104 of "/usr/include/boost/math/special_functions/fpclassify.hpp" instantiation of "bool boost::math_detail::is_nan_helper(T, const boost::true_type &) [with T=long double]" at line 137 of "/usr/include/boost/math/special_functions/fpclassify.hpp" instantiation of "int boost::math::detail::fpclassify_imp(T, const boost::math::detail::generic_tag<true> &) [with T=long double]" at line 242 of "/usr/include/boost/math/special_functions/fpclassify.hpp"
compilation aborted for main.cpp (code 2) ==========
The same code compiles fine under icc 12.0.
I also tried explicitly adding: #define BOOST_MATH_DISABLE_STD_FPCLASSIFY before including the header, but got the same error.
The math library docs say that icc 10.0 and later are fully supported with no serious caveats, so I presume this is a bug. Should I file a ticket? Please let me know if there is any other information about my system which could be useful to know.
Thanks, -Gabe
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Gabriel Redner Sent: Monday, January 03, 2011 5:22 PM To: boost-users Subject: Re: [Boost-users] [math] fpclassify.hpp fails to compile with Intel icc 11.1
Further experiments show that the issue is present in boost 1.42, but fixed in boost 1.45. Sorry for the noise :)
No problems - glad you have got over this hurdle. But I'm curious to know why you are still using 1.42. And also how you found the 'solution'. (This is in no way a criticism, I'm just trying to understand the barrier that users face, or feel, to using the latest version). Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Hi Paul, In this case, no reason at all. 1.42 is the version that comes prepackaged for Ubuntu, so that's what's I had installed. However, this is just a small academic project, so there was really no barrier to downloading 1.45, dumping it into our source tree, and pointing the build at it. On the other hand, I have worked in a large development organization which was quite conservative about upgrading to the newest version of any library or tool. Upgrades take time, and if they temporarily break someone's setup (or even a whole team's!) they can consume a huge number of man-hours. Even worse if the new version brings a new and unknown bug with it. So, those managing our projects tended to be cautious about upgrades. We'd use old versions of libraries, old compilers, everything. We were usually a couple of years behind in our boost version, and our compilers were quite a bit older than that. As long as it worked, we wouldn't touch it until someone could make a good case for the benefits of upgrading outweighing the risks. In the case of this bug, such questions as "Do you *have* to use the boost::math special functions? How much effort would it take to just roll our own? Does the new version bring in any known regressions? How long has the new version been 'in the wild,' and how well is the library vetted in general?" Of course I can only speak from my own experience - I have no idea if such practices are common, but hopefully this is the sort of information you were looking for :) Thanks, -Gabe On Mon, Jan 3, 2011 at 12:51 PM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Gabriel Redner Sent: Monday, January 03, 2011 5:22 PM To: boost-users Subject: Re: [Boost-users] [math] fpclassify.hpp fails to compile with Intel icc 11.1
Further experiments show that the issue is present in boost 1.42, but fixed in boost 1.45. Sorry for the noise :)
No problems - glad you have got over this hurdle.
But I'm curious to know why you are still using 1.42.
And also how you found the 'solution'.
(This is in no way a criticism, I'm just trying to understand the barrier that users face, or feel, to using the latest version).
Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Gabriel Redner Sent: Tuesday, January 04, 2011 3:16 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [math] fpclassify.hpp fails to compile with Intel icc 11.1
Hi Gabe
In this case, no reason at all. 1.42 is the version that comes prepackaged for Ubuntu, so that's what's I had installed. However, this is just a small academic project, so there was really no barrier to downloading 1.45, dumping it into our source tree, and pointing the build at it.
On the other hand, I have worked in a large development organization which was quite conservative about upgrading to the newest version of any library or tool. Upgrades take time, and if they temporarily break someone's setup (or even a whole team's!) they can consume a huge number of man-hours. Even worse if the new version brings a new and unknown bug with it. So, those managing our projects tended to be cautious about upgrades. We'd use old versions of libraries, old compilers, everything. We were usually a couple of years behind in our boost version, and our compilers were quite a bit older than that. As long as it worked, we wouldn't touch it until someone could make a good case for the benefits of upgrading outweighing the risks. In the case of this bug, such questions as "Do you *have* to use the boost::math special functions? How much effort would it take to just roll our own? Does the new version bring in any known regressions? How long has the new version been 'in the wild,' and how well is the library vetted in general?"
Of course I can only speak from my own experience - I have no idea if such practices are common, but hopefully this is the sort of information you were looking for :)
Thanks for this reply. I understand some of the pressures to keep with 'The-Devil-You-Know', but I have a suspicion that these hyper-cautious users don't know how much testing multi-platform Boost code gets, so that things that will bite them are exposed by these tests, no to mention the squeals from early-adopters users who find themselves bitten. But we see a steady stream of users on this list who have been bitten by bugs that have already been squashed in later version. So I feel that even cautious users should be aware that (provided they don't go for the released-today hot off Sourceforge and wait until the dust has settled, perhaps for a few weeks) the balance of risk is much more in favour of using recent releases than they think. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Further experiments show that the issue is present in boost 1.42, but fixed in boost 1.45. Sorry for the noise :)
It's an Intel bug in any case - or at least a result of using the Intel compiler with an unsupported GCC version - just including <cmath> is often enough to trigger it :-( I can't remember the issue number, but I reported it to Intel, and it's been fixed in their most recent compiler releases (as well as a workaround in our code). HTH, John.
participants (6)
-
Gabriel Redner -
John Maddock -
Paul A. Bristow