Thread: Microsoft V6 and V10 C++ differences in integer calculations

I have a large and complex heuristic algorithm code that can be compiled in V6 and V10 without a problem, except that every now and then the different versions deviate in the solution.

All calculations are integer based.

Debugging is possible, but will take quite some time, as there are millions of iterations before deviation occurs over about 19,000 lines of code.

I have checked the obvious such as different int definition, and these all check out, plus compiler flags were setup to match.

I am hoping someone has had a similar problem and can suggest an issue that would help me narrow down my debugging.

Thanks.

Are you saying that your program produces different results in different versions? If so, it looks like an uninitialized variable to me. Does it work the same in debug/release modes? How about different optimization levels?

I tried removing code optimisation levels. No diiference. The difference only appears occasionally, maybe 1 in 100 uses, and I cannot find a pattern to the input data that points to a problem.

Debug mode makes no difference. I am very careful with uninitialised variables, but I cannot discount it, although I think this would cause a higher difference rate.

My thinking is something like a*b*c behaves differently and I might have to force a*(b*c). I have an overflow protector

rmuldiv( a,b,c) which calculates a*b/c safely by converting to longs and back again after calculation. That routine shows no deviation.

All calculations are integer based.

Fortunately debugging aids are not impacting on the solution, so I will get there - just trying to get there a bit quicker.

Can I assume that you've already found some specific input that reproduces the problem every time? Once you've got that then it should be easy to debug both at once and see when they differ.

You can then output iteration numbers and the relevant variables to file from each one. Then afterwards you run a diff tool like WinMerge over the two files to see where they started to differ.
Then you start both again and this time let it run up until the iteration where things differed. You step through that iteration step-by-step and examine every calculation performed.

One of the problems with this type of forum is thhat the original question seems to be lost. I know how to debug - it is slow and tedious. I did accept that with my original question.

I am asking about known issues with V10, that will help me save time by structuring my debugging accordingly to save time.

Does anyone have any known issues tohat could be relevant.

I work on a software library that does extremely long and involved calculations using integers and floating point. The ONLY way we can cope with the complexity to determine why and where something is changed is to write an enormous log file. Once you have your logging, log a run compiled with VC6 and one compiled with VC10, diff them, and you should be able to find where things start to go wrong.

As I have already said I know how to debug with log files several megabytes in size.

V10 is definitely the one with the problem. When it deviates it generates no solution when one clearly exists. I think I said earlier that V1.5 and V6 produce correct and identical results.

So far no-one has come up with anything to reduce the time spent comparing very large log files, which I have had to do many times before - although looking for a compiler difference is a first - usually it is because of a self inflicted bug introduced after a software change!

By the way, we never had any problems with V6, when we converted from v1.5.

Without actually seeing the offending code, it's hard to give specific advice.

However, the logical things to look for would be

1) an uninitialised variable, as already mentioned. Accessing the value of an undefined variable gives undefined behaviour. With some compilers, uninitialised variables get the value zero, and some programmers intentionally or unintentionally exploit that - so their code fails when built with another compiler or version.

2) an operation involving one or more variables of signed int type is going out of range of that int type (again, undefined behaviour)

3) basic types of different sizes. Although operations on unsigned types wrap (i.e. modulo arithmetic) the results will be different between compilers that support different sizes of the basic types. To check that, initially at least, examine sizeof() all the basic types.

4) using integer division or modulus with negative operands. The results are implementation defined in C++.

5) Some other form of undefined behaviour (such as falling off the end of an array, using memory after deallocating it, etc etc). One of the "joys" of code with undefined behaviour is that it can appear to work correctly (however you defined "correctly") with one compiler (or version), but not with another. The code is still wrong, just the symptoms can change.



I doubt the problem is with V10. Microsoft V6 compiler was rather famous both for being buggy and for non-compliance with the C++ standard, and Microsoft made a concerted effort to improve the quality in later versions. It is more likely that your code worked correctly with V6 because of a bug or non-compliance in V6 that your code accidentally exploited, and the problem was corrected in V10.

Try turning up warning levels when compiling your code .... with both versions of the compiler. The most detailed warnings are not emitted by default but, in practice, warnings are usually an indicator of code that is not guaranteed to work with every compiler.

Originally Posted by johnggold

As I have already said I know how to debug with log files several megabytes in size.

No, you have not already said that, nor have you demonstrated that, and I very much doubt that is true or you would probably have solved you bug by now.

V10 is definitely the one with the problem. When it deviates it generates no solution when one clearly exists. I think I said earlier that V1.5 and V6 produce correct and identical results.

There is no way in hell you can claim that with any degree of certainty. The most likely explanation is that your program contains code which is technically undefined behaviour that older compilers let you get away with. Older compilers let you get away with murder, or at least a lot of stupidity. We've seen dozens of cases on that on these forums quite often. It almost always comes down to that, and every man and his dog thinks they've found a compiler error, only to be shown that their code simply had a bug. Your over confidence in your existing code is rather tiresome. Get over it.

So far no-one has come up with anything to reduce the time spent comparing very large log files, which I have had to do many times before - although looking for a compiler difference is a first - usually it is because of a self inflicted bug introduced after a software change!

Rubbish, I gave you a very good way of comparing large log files to find the differences in just a few seconds. And of course if it's more complicated than a straight compare then you haven't found a reliable way of reproducing the problem yet (you never answered my earlier question). Even in such a case you should be able to simply write your own tool to do the compare in say about 15 minutes.

By the way, we never had any problems with V6, when we converted from v1.5.

Not relevant, and not of interest.

You seem to be expecting someone to come and and say something like "Multiplying 42 by 53 gives the wrong answer in VS2010" or some such nonsense. The truth is that there is no such bug. Until you accept that the bug was probably in the code all along or post code that proves otherwise, you're just being foolish.

What a load of nonsense!

First, I have two Microsoft complier bugs confirmed by Microsoft. If you have ever tried this, there are a lot of hoops to jump through. So please don't tell me about non-existent compiler faults. Interestingly, one of the bugs was detected with the software module I am working on now.

Your certainty is worrying. You should read Robert Graves "Broken Images" - it's only short but it does describe your approach very well.

Second, I don't really care whether the problem is a V10 compiler bug or just an undetected feature now exposed. It is still a problem that does not occur with other versions, so it has to be V10 as the problem.

That's why I am looking for any issues that others may have found - it helps focus debugging.

Third, comparisons are fast - I use CompareIT - preparation of two large log files takes about 30 minutes per cycle. Then you have to look at what the differences are telling you, move the debugging, and son. Obviously the process should speed up as the code is narrowed down, but it will take a couple of days.

Between VC6 and 2010 a lot has changed. You left out versions 2002 (good choice), 2003, 2005 and 2008. Each had a few breaking changes, that could be remedied by setting certain compiler flags. None of those were bugs.

For example, time_t changed size in 2005 I think. If you need time_t to be 4 bytes, you need to define _USE_32BIT_TIME_T. There will likely be more changes like that and I don't think there is a document describing changes from VC6 to 2010. You might want to read each versions breaking changes while your debug file is generated.