I work for a major CFD vendor and recent compiler updates make us looking for an alternative compiler as fast as we can. Almost every update brings in new bugs - between internal compiler errors, that can be mostly handled by slightly changing the code and at least there is a clear indication what is going wrong to the worst possible thing - miscompiled code.Out software has over two millions lines of complex C++ code. The recent Intel 12.1 has bugs that are really bad and extremely hard to find because they only occur when /O3 is used. Disabling optimization fixes the problem, but generates impossibly slow code.The most recent bug miscompiles following trivial code:double const c0 = cos(a(0)), s0 = sin(a(0));double const c1 = cos(a(1)), s1 = sin(a(1));double const c2 = cos(a(2)), s2 = sin(a(2));std::cout << a << c0 << " " << c1 << " " << c2 << " " << s0 << " " << s1 << " " << s2 <<std::endl;The a is a structure of three numbers accessed via simple inline function double const& operator()(int const& i) const { return _data; }The output the compiler produces in this case with full optimization is(0.242077 0 0)0.970842 0.970842 0.970842 0.23972 0.23972 0.23972wih global optimization disabled (via #pragma optimize("g",off)the same fragment produces correct output(0.242077 0 0)0.970842 1 1 0.23972 0 0So there is clearly some aliasing logic completely wrong and ignoring anything but the first variable.Should I mention that these bugs are extremely time consuming to find (weeks to be precise) even with very detailed test suite.Optimization flags used:/O3 /Qtemplate-depth-100 /GR /EHsc -QaxAVX
Link Copied
I don't see "an aliasing problem" and I rathersee a roundingproblem. Please take a look atre-formatted outputs:
But, I'm not trying to defend Intel C++ compiler becauseinyour case something is wrong.
I was monitoring Intel C++ compiler forum for about 6 months ( 11.2011 - 04.2012 )in order to get some
information on different problems and bugs. I was able to see that in some simple test-cases Intel C++ compiler was
failing and I didn't like it. However, when a real integration of Intel C++ compiler for the project started
in April everything was really smooth and it was completed in about 2 weeks.
Do you think that a "threat" tostop usingIntel C++ compiler is right? If you don't use another C++ compiler on
your project from the beginning a port ofthe two-million-code-lines project could beanother disaster. Isn't that true?
Could you let me know the five ticket numbers?
And thanks for the small testcase. We're investigating this issue right now.
Jennifer
Strange, I'm not seen the issue: running on a Sandybridge.
C:\Jennifer\Issues\AVX>icl -O3 /MD /Zi /GR /EHsc -QxAVX avx.cpp
Intel C++ Intel 64 Compiler XE for applications running on Intel 64, Ve
rsion 12.1.5.344 Build 20120612
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
avx.cpp
Microsoft Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
-out:avx.exe
-debug
-pdb:avx.pdb
avx.obj
C:\Jennifer\Issues\AVX>avx
1 0.540302 -0.416147 0 0.841471 0.909297
C:\Jennifer\Issues\AVX>type avx.cpp
#include
using namespace std;
class Vec
{
double _data[3];
public:
double const& operator()(unsigned int const& i) const { return _data; }
Vec(double const& a, double const& b, double const& c)
{
_data[0] = a;
_data[1] = b;
_data[2] = c;
}
};
int main(int argc, char* argv[])
{
Vec b(0,1,2);
double const c0 = cos(b(0)), s0 = sin(b(0));
double const c1 = cos(b(1)), s1 = sin(b(1));
double const c2 = cos(b(2)), s2 = sin(b(2));
std::cout << c0 << " " << c1 << " " << c2 << " " << s0 << " " << s1 << "
" << s2 << std::endl;
return 0;
}
C:\Jennifer\Issues\AVX>
Yeh, the addition code brought in a lot of stuff from the header. Now Ican duplicate the issue on the sandybridge, and am sending it to the compiler engineering right now.
I'll update you when there is any progress. Thanks for the testcase again.
Jennifer
This is a test-case that was used to reproduce the problem. Please take a look:
>> Output <<
> Test1017 Start <
Sub-Test 26
0 0.000000 0.0000000000000000 0.0000000000000000 AbsError 1: 0.0000000000 AbsError 2: 0.0000000000
1 0.500000 0.4794255495071411 0.4794255495071411 AbsError 1: 0.0000000000 AbsError 2: 0.0000004470
2 1.000000 0.8414709568023682 0.8414709568023682 AbsError 1: 0.0000000000 AbsError 2: 0.0000000596
3 1.500000 0.9974949359893799 0.9974949955940247 AbsError 1: -0.0000000596 AbsError 2: 0.0000000000
4 2.000000 0.9092961549758911 0.9092974066734314 AbsError 1: -0.0000012517 AbsError 2: -1.8185943961
5 2.500000 0.5984489321708679 0.5984721183776856 AbsError 1: -0.0000231862 AbsError 2: -1.1969441175
6 3.000000 0.1408745944499970 0.1411200016736984 AbsError 1: -0.0002454072 AbsError 2: -0.2822400033
7 3.500000 -0.3525765836238861 -0.3507832288742065 AbsError 1: -0.0017933547 AbsError 2: 0.0000002384
8 4.000000 -0.7668045759201050 -0.7568024992942810 AbsError 1: -0.0100020766 AbsError 2: 0.0000004768
9 4.500000 -1.0228917598724365 -0.9775301218032837 AbsError 1: -0.0453616381 AbsError 2: 0.0000001192
10 5.000000 -1.1336172819137573 -0.9589242935180664 AbsError 1: -0.1746929884 AbsError 2: 1.9178482890
11 5.500000 -1.2947624921798706 -0.7055402994155884 AbsError 1: -0.5892221928 AbsError 2: 1.4110803008
> Test1017 End <
If I remember the problem was related to thebuilt-in x87fsin instruction.MSVCRT sin() functions calls x87 fsin to calculate the values of sine function.
A while ago there was some issue with trigonometric functions ( sine
If I remember the problem was related to thebuilt-in x87fsin instruction...
A while ago there was some issue with trigonometric functions ( sine
For more complete information about compiler optimizations, see our Optimization Notice.