icpc, g++ 4.3.2 and __builtin_isfinite

[wdong_pku]

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?

[TimP]

Quoting - wdong.pku

/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.

[graziano_giulianigma]

Quoting - tim18

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<:__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<:__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<:__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<:__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)

[glazzara]

Hi,

Quoting - graziano.giulianigmail.com

"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<:__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.

[cpp]#include 
using namespace std;
int main()
{
  isfinite(4.0f);
}[/cpp]

Actually, it seems that "using namespace std" is the issue.

[Om_S_Intel]

This seems a bug in Intel C++ compiler.

[Om_S_Intel]

I have reported the issue to Intel compiler development team. I will update the forum community when this is resolved.

[TimP]

Quoting - Om Sachan (Intel)

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.

[Om_S_Intel]

The issue has been fixed by Intel compiler development team. I will let you know when the release compiler is available for download.

[Derek_Baikie1]

Quoting - Om Sachan (Intel)

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?

[TimP]

__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).

[Milind_Kulkarni__Int]

Quoting - tim18

__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 . 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 // 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.

[Lingfeng_C_Intel]

Can we say that the source code can be compiled by GCC and failed in Intel compiler?

Thanks,
Wise

[Rhys_Ulerich]

Quoting - Derek Baikie

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?

Ditto here. Both 11.1.059 and 10.1.022 die during building Boost 1.41 on Ubuntu 9.10 because of this problem. I'd love to know a suggested workaround or a time estimate for a fix to come out.

- Rhys

[rupert_brooks]

Quoting - Rhys Ulerich

Ditto here. Both 11.1.059 and 10.1.022 die during building Boost 1.41 on Ubuntu 9.10 because of this problem. I'd love to know a suggested workaround or a time estimate for a fix to come out.

- Rhys

A potential work around is to install the gcc-4.2 packages, ie

sudo apt-get gcc-4.2 g++4.2

And then to use the -gcc-name, -gxx-name options of icpc

icpc -gcc-name=gcc-4.2 -gxx-name=g++-4.2 -I/usr/local/include/boost-1_40/ -o testexec test.cpp

So far, works on a simple boost case that was failing before.

[Rhys_Ulerich]

Quoting - rupert_brooks

Quoting - Rhys Ulerich

Ditto here. Both 11.1.059 and 10.1.022 die during building Boost 1.41 on Ubuntu 9.10 because of this problem. I'd love to know a suggested workaround or a time estimate for a fix to come out.

- Rhys

A potential work around is to install the gcc-4.2 packages, ie

sudo apt-get gcc-4.2 g++4.2

And then to use the -gcc-name, -gxx-name options of icpc

icpc -gcc-name=gcc-4.2 -gxx-name=g++-4.2 -I/usr/local/include/boost-1_40/ -o testexec test.cpp

So far, works on a simple boost case that was failing before.

The --{gcc,gxx}-name options do get me past the simple test case posted earlier in this thread. Any suggestions for how to incorporate those flags into an environment variable or some configuration file so that icpc uses the GNU 4.2 settings all the time? The documentation on those flags doesn't suggest anything.

FYI: 11.1.064, the Update 4 that just recently came out, still does not address this problem. Hopefully that'll save someone a lot of downloading and installation time.

- Rhys

[Rhys_Ulerich]

Quoting - Rhys Ulerich

The --{gcc,gxx}-name options do get me past the simple test case posted earlier in this thread. Any suggestions for how to incorporate those flags into an environment variable or some configuration file so that icpc uses the GNU 4.2 settings all the time? The documentation on those flags doesn't suggest anything.

As a clarification, some method other than setting CFLAGS and friends...

[TimP]

Put the options in icc.cfg and icpc.cfg in the compiler installation, if you like.

[Rhys_Ulerich]

Quoting - tim18

Put the options in icc.cfg and icpc.cfg in the compiler installation, if you like.

Thanks for the suggestion Tim.

Sticking
-gcc-name=gcc-4.2
-gxx-name=g++-4.2
in each of those two files allows Boost 1.41 to build successfully using 11.1.064 on Ubuntu 9.10.

- Rhys

[Om_S_Intel]

The issue is resolved in latest Intel C++ compiler. The compiler is available for you to download for Intel Registration and Download center.

[Blue_Sky_Studios]

What is the latest compiler? I downloaded an eval copy today and got 11.1-064. It still has this problem.

[hfifnet]

This is definitely NOT fixed for:
$ g++ -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)

...neither for:
$ g++ -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)


in conjunction with:
$ icpc --version
icpc (ICC) 11.1 20100414
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

The software I am trying to compile is GNU octave-3.2.4, with CXXFLAGS="-DMKL_ILP64 -malign-double -fp-model strict -g -fPIC -align -falign-functions=16 -ansi-alias -fno-alias -axSSSE3 -m64 -march=core2"

Are there any non-invasive workarounds?