Hi,
I'm trying to understand what appears to be a bug in icpc 9.x. I know this has been fixed in 11.x (don't know about 10.x) but I am, unfortunately, stuck on the older version for now. I have workarounds; I'm trying to undersand the nature of this problem, especially the conditions under which it occurs.
Consider this example, paying attention to funciton f, and the initialization of c:
#include
#include
typedef std::complex complex_t;
void f(complex_t & a, complex_t b) {
if (true) a = b;
else a = b; // <<<** DELETING THIS LINE ELIMINATES THE BUG **>>>
}
int main() {
complex_t a(1, -2);
complex_t b(3, -4);
complex_t c = a + b;
std::cout << "a: " << a << std::endl
<< "b: " << b << std::endl
<< "c: " << c << std::endl;
return 0;
}
[63] % /depot/intelcc-9.1.049/intel64/icc/bin/icpc -O0 b.c && a.out
a: (1,-2)
b: (3,-4)
c: (-1.99905,1.77965e-43)
[64] % /depot/intelcc-11.0.074/bin/intel64/icpc -O0 b.c && a.out
a: (1,-2)
b: (3,-4)
c: (4,-6)
[65] % g++ -O0 b.c && a.out
a: (1,-2)
b: (3,-4)
c: (4,-6)
[66] % g++ --version
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20)
Where does the garbage value for c come from? How in the world does the definition of f, which is not called, affect the value of c??
I assume that this is a known (and subsequently, fixed) bug. I need to know the conditions under which this occurs so that I can avoid it in the future. Right now, it's now at all clear.
Also, why isn't the Intel knowledge base searchable? We could have all saved ourselves a bit of trouble if I had had a way to search a full list of known bugs for icpc ver 9.x!
Thanks,
-Andy