Serious bug in Visual C++ 6.0?

[Matthew Smith]

Hi, I believe that my colleagues and I have discovered a bug in the Visual C++ 6.0 compiler. We're using Visual C++ 6.0 sp3 on NT 4.0 sp6a. The following C++ code will compile and give the correct results (11) if compiled in debug or /O (optimize for space) mode. If compiled for speed, with /02, it gives incorrect results (2). Here is the code:

#include <iostream.h>

double tol=-1.0;

int main(void) {

double grid[11];
int ci=0;
grid[ci] = 0.0;

while (grid[ci]<10.0) {
double step_to_end = 10.0 - grid[ci];

if (tol>0.0) cerr << "should not be here" << endl;

if ( 1.0>(step_to_end-0.0) ) {
// cerr << "really shouldn't be here" << endl;
ci++;
grid[ci] = grid[ci-1] + step_to_end;
} else {
#if 0
grid[ci+1] = grid[ci] + 1.0;
ci++;
#else
ci++;
grid[ci] = grid[ci-1] + 1.0;
#endif
}
}

cout << endl << "num points: " << ci+1 << endl;
return ci+1;
}




Is this a known bug? Do patches exist? It's a little scary that something this simple produces incorrect compiled code. Any input is greatly appreciated.

-Matt Smith

[Jason Brooks]

It not obvious where the bug or what the symptoms are, however VC++ has a problem with the ordering of post incremental expressions within the same line.

i.e. Function(x,x++);
where x=2
becomed Function(2,2);
x=3;

Under Debug, x is incremented correctly, release/optimised the result is something like

Function(3,2);
x=3;

Jason
www.muckypaws.com

[Jon Funk]

SP3 fixes this problem ... I think. The problem resides with the use of the loop optimization (/Og or /O2) flag. However, many problems still remain with the /Og flag. So yes, this is a known problem. But I'm not sure in SP3 fixes it ... all. There are still some other loop problems that remain unsolved. Microsoft documents each of these on their known problems page on their website. Hope this helps ...