Intel® C++ Compiler

Compilation error with icc v8.1 on Linux

Using icc v8.1 on Linux (gcc 3.3.4), the simple code (I had to remove the brackets in the include statements to keep the software from thinking it is html)

#include iostream
#include cmath
#include cstdlib

using namespace std;

int main() {
float x = 0.0f;
if (isnan(x))

gives the compilation error

$ icc
/tmp/iccGk3Prtas_: Assembler messages:
/tmp/iccGk3Prtas_:103: Error: suffix or operands invalid for `movs'

Problem with complex float functions on Linux/C++ V8.1

The simple code: (put "float" in brackets for the template instantiation below. The bulletin board software "helpfully" removes what it thinks is bad html)

int main() {
std::complex float a = log(std::complex float (3.0f,0.0f));

gives the compilation error

$ icc
/tmp/icclE1hwc.o(.text+0x78): In function `main':
: undefined reference to `__builtin_logf'

This program was not built to run on the processor in your system

I have to assume I'm getting this message becuase I've built an itanium exe. However, I'm using the same make files from prevus projects, now with 8.1 I'm gettting this error. I've tried forcing the processor verions with /QxW, but still it give me the same error.

Any ideas?


IC 8.1 does not save warning state when using precompiled headers

I have a config header which disables some (almost) useless warnings when compiling with /W4 (operands are evaluated in unspecified order, value copied to temporary and so on). Since that file doesn't change very often, it seems natural to include it in the pch. But it looks like ICL 8.1 does not save its warning state in the pch.
Workaround: use /W3 or do not use pch

Loop Index preferred type

Simple questions, I'm almost embarrassed to be posting this...

For a simple standard loop

for (i=0;i

1. Does it make any difference if the quantities are signed or unsigned ? (Both the same type preferred, obviously)

2. How about short or int, assuming the numbers are small enough ? Do
shorts automatically get cast to int by the compiler ? Is it useful to declare
shorts and let the compilercast as it sees fit ?

Doubt it matters, but my applications run on a Xeon(P4) with -O3 -xN

unresolved reference to pthread_atexit when static linking

I'm seeing the following linker eror that I'm unable to resolve:

/opt/intel_cc_80/lib/libguide.a(z_Linux_util.o)(.text+0x17c2): In function `__kmp_suspend_initialize':
: undefined reference to `pthread_atfork'

I'm linking with:

icpc -g -openmp -static object-files -lrt -lpthread

Note that my code does not use pthread_atfork anywhere - it's the -static option that's causing the problem here, and whether -lpthread is on the command line makes no difference either which way.

Any ideas?

Many thanks,

Problem after installing icc 8.1


Since verion 8.1 of the Intel C++ compiler is out, I decided to upgrade to it.

In order to do that, I first uninstalled all other Intel compilers and tools I had on my system (C++ 8.0 with substitute headers, Fortran 8.0 and idb 7.3.2). I left only the license files where they were (/opt/licenses). Subsequently, I downloaded the latest 8.1 package from (package l_cc_p_8.1.021.tar.gz) and unpacked it with the command:

gzip -cd l_cc_p_8.1.021.tar.gz | tar -x

Subscribe to Intel® C++ Compiler