Fundamental compiler error ! I can't believe what I'm seeing ! HELP !!!

Fundamental compiler error ! I can't believe what I'm seeing ! HELP !!!

The attached default Windows code project with a single, simple "for" loop
exhibits a major mis-compilation. It is small and repeated right here
below:

// TODO: Place code
here.
inti;
intArray[5] = { 0, 1000, 2000,
3000, 40000 };
intresult = 0;
intLoopLimit =
5;
intDesiredIdx = 3;

for (i=0; i{
if (i ==
DesiredIdx)
{
result =
Array[i];
break;
}
}

// The
Bug - The variable "result" should be equal to 3000
// It is coming out
as 0. !!

To recreate, create a new project in VS2005 or VS2008 and plunk this code down into it and step through it. I'm using VS2005 and VS2008 with Intel C++ compiler 10.1.022. I can't believe what I'm seeing !

Can anyone tell me WHY !!!

16 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I don't have a good answer for you yet, but wanted to assure you that I'm looking into it. I'll update here when I have more info.

Thanks!

Dale

Same problem here (result being 0 not 3000) on linux w. icpc (ICC) 10.0 20070809

You would have to add some use of result at the end of the segment to be more convincing in your argument that the compiler should not decide that result is not used, and therefore need not be set conditionally at run time. I think you can construct a full example, where -Wall doesn't complain, which still shows an apparent bug.

He's right. It's a bug,and the zero isn't the default value of result, it is the first element of Array. If you put something in the loop so the compiler can't optimize the loop away then the problem goes away. For instance uncomment the cout in the following. It's odd that the compiler tries to compute the value of result at compile time evenwith Od.

// intel_cpp_test.cpp : Defines the entry point for the console application.

//

#include "stdafx.h"

#include

int fun( )

{

int Array[] = { 666, 1000, 2000, 3000, 40000 };

int result = -2;

int LoopLimit = 5;

int DesiredIdx = 3;

for ( int i = 0; i < LoopLimit; ++i )

{

//std::cout<<"hi";

if (i == DesiredIdx)

{

result = Array[i];

break;

}

}

return result;

}

int _tmain(int argc, _TCHAR* argv[])

{

char str[512];

int len = 2;

std::cout << fun() << " ";

std::cin.getline(str, len);

return 0;

}

[edit]

Actually, the compiler isn't trying to compute "result" at compile time. It is executing some instructions for the loop whether the cout is there or not. It just executes a correct set of instructions when cout is there :)

@tim18

Well obvoiusly that has been tried, i assume printing out the number would require it to be computed.
- also i get no errors/warnings (-Wall) during compilation: > icpc -ansi -Wall result.cpp

using the source below (which prints out "result = 0" and "result = 3000" with icpc and g++ respectively)

#include
int main()
{
// TODO: Place code here.
int i;
int Array[5] = { 0, 1000, 2000, 3000, 40000 };
int result = 0;
int LoopLimit = 5;
int DesiredIdx = 3;

for (i=0; i {
if (i == DesiredIdx)
{
result = Array[i];
break;
}
}
printf("result = %i
", result);
}

funny - try this :

replace the line:

if (i == DesiredIdx)

with:

if (DesiredIdx == i)

- it suddenly works for me..

Funny or scary ? We just started with this compiler and I'm not feeling too good about it.
Just remove the break; from the code in my original post and let the loop fully exhaust itself
(not as efficient), and it works also. I say scary !

It's unbelievable, and it's scaring!

I just tested with my icl9.1 in debug in VS2003. It turn out to be get the result of Array[0]. And if you decorate DesiredIdx with const, you can get right result 3000. And if you rewrite i == DesiredIdx with DesiredIdx ==i, you get right result too.

Waiting..........

Thanks for posting this issue. I'm working on getting this fixed, and it should be fixed in a future release. I'm also working to see if there are any reliable workarounds and will post again when I have more info.

Dale

Hi Dale,

Have you come up with any reliable workarounds to this problem ? Do you know if any earlier versions of the compiler that did not have this issue ?

Thanks

The good news is that this should be fixed in the next 10.1 update (and every other compiler we ever produce again :-). The bad news is that the best workaround was the one mentioned previously in the thread, removing the break. Of course, in this simple test case, all you really need to do is check that DesiredIdx is in the range of the loop index, i.e. you don't really need the loop at all,but I don't suppose that maps back nicely to the original source code.

Any time you get a result that is so obviously wrong, the first thing to suspect is the optimizer. That is one reason Debug builds have optimization disabled. It used to be more common to disable optimization for selected parts of code for a given platform or compiler. Now days, optimizer bugs are realtively rare, even at the highest optimization level.

Of course, this one is a surprisingly bad optimizer error. Usually, things need to be rather complex to find an optimzier bug now days.

The new 10.1 compiler update (10.1.025) contains the fix for this issue. See below.

C:>icl mytest.cpp
Intel C++ Compiler for applications running on IA-32, Version 10.1 Build 20080801 Package ID: w_cc_p_10.1.025
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

mytest.cpp
Microsoft Incremental Linker Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved.

-out:mytest.exe
mytest.obj

C:>mytest.exe
i=3 result=3000
C:>

Thanks,
Feilong

I agree it's fixed ! 10.1.025 solves the problem.

Thanks to Intel for their quick response.

-Pat

Does this affect 9.1.040 and if it does will it be fixed?

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Login to leave a comment.