bug in icpc version 11.0 with -O3?

[Anonymous]

I have attached a cpp file which defines a function called printjunk(int dim). It is supposed to print

1, 1/2, 1/3, ... up to dim terms

in double precision.

Instead it prints all ones. However if the commented out line

//cout<<"A"<

in uncommented it prints correctly.

The following command were used to compile, link and compile to assembly.

icpc -O3 -prec-div -no-ftz -DNDEBUG -c bug.cpp

icpc -L/usr/caen/intel-11.0/fc/11.0.074/lib/intel64 -o bug.exe bug.o -lmkl_intel_lp64 -lmkl_sequential -lmkl_lapack -lmkl_core -lpthread -lifcore -lm

icpc -O3 -prec-div -no-ftz -DNDEBUG -S bug.cpp

I have attached the assembly for the buggy version as bug.a.s. I have attached the assembly for the non-buggy version (with "cout<<"A"<

This bug goes away if the compilation uses the debug option -g instead of -O3.

What is going on? The icpc version is 11.0

[TimP]

As the behavior seems to be OK with -fp-model source (which includes -prec-div -no-ftz), it seems that you may be depending on the compiler following standards for expression evaluation. I don't see either how it can treat that stuff as loop invariant, but your example reinforces the recommendation to set -fp-model source until you can prove you need more aggressive optimization. Many of the optimizations which are inhibited by this option can be restored one loop at a time by the #pragma simd stuff in current icpc.

[Om_S_Intel]

The icc uses -fp-model fast=1 as default. In this case compiler goes for more agrresive optimization but produces less accurate result.

I do not think it is a bug. If you do not like the result produced by -fp-model fast=1, you may use a different option to get the accuracy of your your choice using -fp-model option.

[levicki · Accepted solution]

Om,

I would not call printing 1.0 instead of 0.5 "less accurate result" -- it is an outright error and it has nothing to do with fp model selection.

If you check the source code, it seems that the compiler optimizer incorrectly assumes that the value of lambda(i) doesn't change after a call to equate() (which sets it to 1.0) so it "optimizes" away the following part of the expression:

lambda(i)[0] = 1.0/(r(i)[0]);

Leading to the aforementioned error.

I tried to construct minimal test case but could not reproduce it here with Composer 2011 Update 1. Perhaps it has been fixed in the latest version of the compiler. If not, you should try to reproduce with given code example and if you succeed submit a case to premier support.

[Om_S_Intel]

I can reproduce it using icc 12.0.

I have submitted a report to Compiler development team on this. I will update this tread when I have more information.

[Anonymous]

Thank you Igor. I noticed that the bug did not occur with -O2 and I have been using that. I came back to look at this thread only today. -O3 generates incorrect code. I think it gets confused by some of the C++ constructs.

[levicki]

You are welcome :)