icpc, g++ 4.3.2 and __builtin_isfinite
I get the following compiling error:
/usr/local/include/c++/4.3.2/cmath(522): error: identifier "__builtin_isfinite" is undefined
return __builtin_isfinite(__type(__f));
^
Does it mean icpc cannot work with g++ 4.3.2?
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
/usr/local/include/c++/4.3.2/cmath(522): error: identifier "__builtin_isfinite" is undefined
return __builtin_isfinite(__type(__f));
^
Does it mean icpc cannot work with g++ 4.3.2?
In my current g++ installation, this version of isfinite is invoked when not using tr1 headers and when _GLIBCXX_USE_C99_MATH is set. So, it looks like you don't want the g++ C99 headers to be active.
I don't understand how you got to this point; did you set gcc or icc -std=c99 somewhere, and then attempt to mix in g++ or icpc? A working example (the smaller, the better) may be needed.
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
In my current g++ installation, this version of isfinite is invoked when not using tr1 headers and when _GLIBCXX_USE_C99_MATH is set. So, it looks like you don't want the g++ C99 headers to be active.
I don't understand how you got to this point; did you set gcc or icc -std=c99 somewhere, and then attempt to mix in g++ or icpc? A working example (the smaller, the better) may be needed.
Well, I have found this in a not so little example...
I am trying to compile boost c++ library 1.38 with icpc (have installed g++ 4.3.3) on Linux.
Compiling fpclassify.cpp
"icpc" -std=gnu++98 -c -O3 -finline -finline-functions -w1 -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/math/build/intel-linux/release/threading-multi/fpclassify.o" "libs/math/build/../src/tr1/fpclassify.cpp"
/usr/include/c++/4.3.3/cmath(522): error: identifier "__builtin_isfinite" is undefined
return __builtin_isfinite(__type(__f));
^
detected during:
instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::isfinite(_Tp) [with _Tp=double]" at line 262 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::detail::isfinite_impl(T, const boost::math::detail::native_tag &) [with T=double]" at line 310 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::isfinite(T) [with T=double]" at line 26 of "libs/math/build/../src/tr1/fpclassify.cpp"
/usr/include/c++/4.3.3/cmath(531): error: identifier "__builtin_isinf" is undefined
return __builtin_isinf(__type(__f));
^
detected during:
instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::isinf(_Tp) [with _Tp=double]" at line 380 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::detail::isinf_impl(T, const boost::math::detail::native_tag &) [with T=double]" at line 445 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::isinf(T) [with T=double]" at line 31 of "libs/math/build/../src/tr1/fpclassify.cpp"
/usr/include/c++/4.3.3/cmath(540): error: identifier "__builtin_isnan" is undefined
return __builtin_isnan(__type(__f));
^
detected during:
instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::isnan(_Tp) [with _Tp=double]" at line 456 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::detail::isnan_impl(T, const boost::math::detail::native_tag &) [with T=double]" at line 514 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::isnan(T) [with T=double]" at line 36 of "libs/math/build/../src/tr1/fpclassify.cpp"
/usr/include/c++/4.3.3/cmath(549): error: identifier "__builtin_isnormal" is undefined
return __builtin_isnormal(__type(__f));
^
detected during:
instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::isnormal(_Tp) [with _Tp=double]" at line 321 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::detail::isnormal_impl(T, const boost::math::detail::native_tag &) [with T=double]" at line 369 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::isnormal(T) [with T=double]" at line 41 of "libs/math/build/../src/tr1/fpclassify.cpp"
compilation aborted for libs/math/build/../src/tr1/fpclassify.cpp (code 2)
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
"icpc" -std=gnu++98 -c -O3 -finline -finline-functions -w1 -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/math/build/intel-linux/release/threading-multi/fpclassify.o" "libs/math/build/../src/tr1/fpclassify.cpp"
/usr/include/c++/4.3.3/cmath(522): error: identifier "__builtin_isfinite" is undefined
return __builtin_isfinite(__type(__f));
^
detected during:
instantiation of "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type std::isfinite(_Tp) [with _Tp=double]" at line 262 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::detail::isfinite_impl(T, const boost::math::detail::native_tag &) [with T=double]" at line 310 of "./boost/math/special_functions/fpclassify.hpp"
instantiation of "bool boost::math::isfinite(T) [with T=double]" at line 26 of "libs/math/build/../src/tr1/fpclassify.cpp"
I encountered the same kind of problems while compiling the library Trimesh.
I have found a small test case to reproduce this problem.
#include <cmath>
using namespace std;
int main()
{
isfinite(4.0f);
}
Actually, it seems that "using namespace std" is the issue.
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
This seems a bug in Intel C++ compiler.
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
I have reported the issue to Intel compiler development team. I will update the forum community when this is resolved.
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
I have reported the issue to Intel compiler development team. I will update the forum community when this is resolved.
According to this example, current icpc supports g++ 4.2.1 headers, but not current g++. Due to the divergence between C99 and C++, I suppose it's difficult to tie down all the loose ends.
There have been other examples of unsatisfactory support of new gcc built-in functions. The compiler team advised me to avoid C++ copy() on account of the way they chose to implement the corresponding built-in, and the discrepancy between the usual implementations which take care of cases where C++ standard makes the result undefined.
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
indicates that the treatment of built-ins should depend on -std= setting. icc supports only a minimal subset of the gcc -std= options (not, for example, the -std=gnuxx), and those not apparently in accordance with gcc documentation on built-ins.
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
The issue has been fixed by Intel compiler development team. I will let you know when the release compiler is available for download.
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
The issue has been fixed by Intel compiler development team. I will let you know when the release compiler is available for download.
I'm using build 059, 441, ubuntu 9.10; and still see this issue.
(actually breaks the latest boost build of 1_40_0)
Can you confirm whether this fix has been released or not?
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
__builtin_isfinite continues to fail with all versions of icpc for x86_64 which I have available (on RHEL5.2, with gcc 4.5 on path).
| |
Re: icpc, g++ 4.3.2 and __builtin_isfinite
__builtin_isfinite continues to fail with all versions of icpc for x86_64 which I have available (on RHEL5.2, with gcc 4.5 on path).
I tried with mathimf.h instead of <cmath> . May be Because some c99 funcs like isfinite, fpclassify (from ISO C 99 standard) is supported by Intel LIBM, but not Microsoft Windows* or gcc in Linux*, the Intel library mathimf.h file should have been used. Hence following should be tried the following header files for the testcase:
#include <mathimf.h> // Header file from Intel Compiler
using namespace std;
int main()
{
isfinite(4.0f);
}
Then, we get correct result with gcc 4.4.x , for eg.
icpc test.cpp -- provides correct result.
Though don't know whether this is workaround, or it should work like this only.
| | |
