Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Divakar_V_
Beginner
112 Views

bug in icpc version 11.0 with -O3?

Jump to solution
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
0 Kudos
1 Solution
ILevi1
Valued Contributor I
112 Views
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.

View solution in original post

6 Replies
TimP
Black Belt
112 Views
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
Employee
112 Views
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.
ILevi1
Valued Contributor I
113 Views
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.

View solution in original post

Om_S_Intel
Employee
112 Views
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.

Divakar_V_
Beginner
112 Views
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.
ILevi1
Valued Contributor I
112 Views
You are welcome :)
Reply