icc on SuSE 10.0 with gcc 4.0.2

[sinate]

Hi,

I'm using icc 9.0.027 on SuSE 10.0, which has gcc 4.0.2. My code used to compile fine under SuSE 9.3, but not now.

I get the following errors with this icpc command:

icpc -O3 -xP -vec_report3 -restrict -w1 -DNO_PAPI -I. -I/usr/local/intel/ipp/5.0/ia32/include -I/usr/local/include -c vml_compare_inst.cpp

/usr/include/c++/4.0.2/cmath(354): error: identifier "__builtin_powi" is undefined
{ return __builtin_powi(__x, __i); }
^

/usr/include/c++/4.0.2/cmath(358): error: identifier "__builtin_powif" is undefined
{ return __builtin_powif(__x, __n); }
^

/usr/include/c++/4.0.2/cmath(362): error: identifier "__builtin_powil" is undefined
{ return __builtin_powil(__x, __n); }
^
I guess it is some compatability porblem. I've put a support request in, but thought I'd post it here to see if any one has come across this problem and solved it.

Thanks,

Steve.

[TimP]

Yes, it looks like icpc doesn't support this relatively new gcc feature. It wouldn't hurt to have your case submitted as a problem report on premier.intel.com, as gcc 4.x support surely will be required soon in icc.
In the mean time, I suppose the easiest solution would be to modify those header files to something more traditional, for example by adding (untested):
inline double __builtin_powi(double x, int i){
return pow(x,i);
}
.....

[sinate]

OK. Thanks. I'll have a go at that.

Support just said SuSE 10.0 with glibc 2.3.5 is unsupported. How long does it normally take you to catch-up with a new gcc feature (roughly)?

Cheers,

Steve.

[sinate]

I tried putting that bit of code before the offending pieces of code in cmath. But I got the following errors:

/usr/include/c++/4.0.2/cmath(364): error: more than one instance of overloaded function "std::pow"
matches the argument list:
function "std::pow(float, float)"
function "std::pow(double, int)"
argument types are: (float, int)
{ return pow(x,i); }
^

/usr/include/c++/4.0.2cmath(373): error: more than one instance of overloaded funtion "std::pow"
matches the argument list:
function "std::pow(long double, long double)"
function "std::pow(double, int)"
function "std::powfloat, int)"
argument types are: (long double, int)
{ return pow(x,i); }
^

This is the code I put into cmath file:

// Added fix for icc 9.0.027
inline double __builtin_powi(double x, int i)
{ return pow(x,i); }

inline double
pow(double __x, int __i)
{ return __builtin_powi(__x, __i); }

// Added fix for icc 9.0.027
inline float __builtin_powif(float x, int i)
{ return pow(x,i); }

inline float
pow(float __x, int __n)
{ return __builtin_powif(__x, __n); }

// Added fix for icc 9.0.027
inline long double __builtin_powil(long double x, int i)
{ return pow(x,i); }

inline long double
pow(long double __x, int __n)
{ return __builtin_powil(__x, __n); }

Any ideas?

Cheers,

Steve.

[TimP]

My idea, not necessarily correct, is to implement temporarily the builtins in terms of the existing pow() function(s). I would not want to attempt to redefine or overload anything which already exists in the libraries. It looks like you don't need to declare any pow() functions, they should already be available. If the C++ machinery already implements overloaded versions of pow(), and you can make them work, fine. In original C, of course, there is only the double pow(double, double).
Full C provides also float powf(float, float) and long double powl(long double, long double). I am not prepared to guess at the suitability of these for your purpose.

Message Edited by tim18 on 11-17-2005 02:42 PM

[mouna_hammami]

hello tim, I know that you are connected now that's why I m writing to you now and here.
Please I need a very very quick help! I m a student and I m working with MKL free version on linux and I have to use lapack function zgesvd in a program written in C.
I really don't know what to do. I spent 2 days trying to performe this but I have this message:
/tmp/ccRHNzdn.o(.text+0x7d): In function `main':
: undefined reference to `PrintArrayD'
/home/intel/mkl/8.0/lib/32/libmkl_lapack.a(mkl_support.o)(.text+0x33f): In function `mkl_serv_s_cos':
: undefined reference to `cos'
collect2: ld returned 1 exit status

please, help me quikly, I have to de this for tomorrow and I don't know how to proceed! what I have to do to make links??

[TimP]

We do read the MKL forum. If no one has answered, it may be on account of your question not being clear. Your current question might be missed by people who could help, since you tacked it on an unrelated thread. Have you followed the examples or advice about linking which come with MKL, to see that you have the general idea, before attempting to adapt it to your own problem? Could you post a small example on the MKL forum, showing details of what you are doing? It looks like you have a problem in your own source code, with a function which either didn't compile, or doesn't exist with the name you gave it, in addition to possibly not specifying -lm for your link.

[TimP]

I understand there is some work going on for icc with gcc 4.0.2 (on Red Hat). I don't know to what extent icc 9.1 would improve support of gcc 4.0.2. If you would post a small example, I could try it on the beta compiler, or you could submit your example on premier.intel.com.

[mouna_hammami]

thank you very much tim,
In fact, when I added -lm it works!
thanx again :)

[karsten_burger]

Hello,

use compile/link option "-cxxlib-icc", thus tellling him to use not the gcc but its own C++
libraries.

Greetings,

Karsten

[TimP]

Thanks for pointing out this work-around. According to my understanding, -cxxlib-icc has been available only for 32-bit and ia64 compilers, and is likely to disappear fromm icc over the next year. As this issue demonstrates, icpc will need compatibility with gcc-4 within that time period.

[John_O_Intel]

icc does officially support gcc 4.0. As SuSE 10.0 hasn't been released yet, icc doesn't yet support it. I suggest opening an issue at http://premier.intel.com so you will be notified when we add support for this.

regards,

_

_|ohnO

[Ganesh_R_Intel]

This issue was fixed in the 9.1 branch of the compiler. The fixes did not make it to 9.0 and therefore requires a workaround. My apologies for thinking this was fixed in 9.0.

>Please note that if you are using a newer version of icc 9.0 this issue should be fixed. It was fixed in an update last Oct.

Message Edited by grao on 03-01-2006 02:46 PM