icpc 12.1 and gcc 4.6, undefined reference to `__builtin_signbit'

[woodbird]

The following simple codes compiles successfully with g++ 4.6 but failed with icpc 12.1, update 7, on ubuntu 11.10, boost 1.46.1

=== begin of code ===

#include

int main ()

{

double x = boost::math::gamma_p_inv(0.5, 0.5);

return 0;

}

=== end of code ===

=== begin compilation commands used ===

icpc -o foo foo.cpp -std=c++0x

=== end compilation commands used ===

The compilation fails with the error as stated in the title of this thread: undefined reference to `__builtin_signbit'.

Many other boost involved codes fails with the same or similar errors, and yet another many fails with all kinds of errors while using icpc with gcc 4.6.

If I disable the `std=c++0x` flag, a lot more errors are generated.

[TimP]

Are you saying that it works with an earlier version of gcc combined with icpc?
I got the same undefined references using red hat gcc 4.4.4 or 4.7 with icpc 12.1.1 and red hat boost.
icpc 12.1.1 appears to have caught up to g++ in the syntax used here but not in implementation of builtins.

[woodbird]

I mean the code compile sucessfully with g++ (no icpc involved at all). But failed with icpc 12.1 when used on a platform with g++ 4.6. However, the same code successfully compile with icpc when used on Mac OS X(but that is totally another story and I don't think is releavant here, since Apple now don't even deliver pure gcc/g++ in Xcode 4.2, they supply llvm-gcc, etc)

Update: I just tested it on Red hat Linux 6.2 beta, with boost 1.47, and gcc/g++ 4.4.6, the same error remains. It happends also for the systems's default boost 1.41

[Judith_W_Intel]

This is already entered in our bug tracking system as cq #172180.

Here is a description of the problem:

When compiling and linking the attached program with icc, there is an undefined reference to the symbol __builtin_signbit. The progam compiles and links as expected using g++.

Sample program:

int main() {
double a = 0.0;
if (__builtin_signbit(a)) {
return 1;
}
return 0;
}

This defect was found when trying to build gzip 1.4 "out of the box" with icc.

It's on the "Must Fix" list for our next update so I expect it will be fixed soon.

Judy

[Om_S_Intel]

I will update the thread when the issue is fixed by INtel compiler development team.

[Om_S_Intel]

The issue is fixed in latest Intel C++ Composer XE 2011. The composer is available from "Intel Regiatration and Download Center".

[drMikeT]

Hello,

how can I make intel C/C++ (12.1.x) use a GCC installation different from the "system" one which is way out of date?

The kernel came was built with GCC 4.1.2 which supports very little of c++0x features but we have users who need to use some of the latest c++0x features.

Is there any known undesirable effect from making intel C/C++ use a different GCC as a basis ? Can we switch at will among GCC installations?

best regards
michael

[TimP]

It's only necessary to put the g++ you want first on PATH and LD_LIBRARY_PATH, so that g++ -v shows you the intended version.
If you were to rebuild the kernel, or a driver which refers to kernel source, you might have a case for reverting to the corresponding gcc version for that task.
Most current linux distros which provide a gcc 4.1 kernel also provide an optional gcc/gcc++ of at least version 4.4.
For C++0x features you likely want a recent g++ 4.6 to go with icpc 12.1, and you may wish to upgrade to a current g++ when icpc 13.0 is released. You may wish to avoid mixing C++ .o files built with different major underlying versions of g++.
I give only personal opinion based on limited experience on this subject.

[drMikeT]

Thanks Tim, I will install a recent GCC for our oldish RHEL environment. Do you think there is any benefit to use C/C++ 13.x on a non-sandy/ivy bridge architecture?

mike

[TimP]

An evident advantage of icpc 13.0 is compatibility with g++ 4.7. There are cases of performance improvement for earlier architectures, as well as improved support for AVX, AVX2 (not yet in released hardware) and MIC.