Bug in Visual Studio 2005 compiler?
-
You should be aware that asking us which optimized code would work and which wouldn't, without posting the full code with declarations and optimizer settings is ludicrous. Therefore I decided to derive it based on you statements elsewhere: Variant B contains code that works by your own statement elsewhere. neither contains the max() funtion you refer to in your original question. So B is the working and A the not working - albeit not the original - version. Q. E. D. As for what is pointless or not: advice is only pointless if it isn't heeded. You believe that the debugger shows you every information correctly? It doesn't. It can't. It's physically impossible. I've dealt with optimizers 30 years ago: back then it wasn't to hard to anticipate what it would do, and in C you could often emulate pretty much the same without having to invoke the optimizer at all. meaning well optimized C code ran almost as well in debug mode as it did in release. I've dealt with optimizers 20 years ago, and it got more tricky. Still, well optimized C-code often turned out to be near optimal. I've dealt with optimizers 10 years ago, and the experience was very different: for one, the same optimizations in C code sometimes led to slower code, because it prevented the optimizer from performing extremely sophisticated optimizations that you'd never have thought of. Plus the size of the codebase made it impossible to optimize all of your code in that way anyway. At that point I stopped trying to optimize my C/C++ code by hand. Nowadays, when I check release code that doesn't do the same as debug code, I often find that half the variables aren't on stack, and some others get overwritten at unexpected moments. At least when I look at them through the debugger. It's the optimizer at work! What I usually do is pinpoint the location where everything goes south, then insert some print statements to ensure everything is as I expect it to be - and in 9 cases out of 10, something will not be as I expect it to be! And the debugger won't be able to show it! That's why I keep telling you not to trust the debugger - and looking at the assembler code doesn't change that you're using the debugger.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote: Therefore I decided to derive it based on you statements elsewhere: Variant B contains code that works by your own statement elsewhere. neither contains the max() funtion you refer to in your original question. So B is the working and A the not working - albeit not the original - version. Q. E. D. Again- I never claimed, which variant works and which does not. It was my question. And what "not the original version" means? I made my own investigation since the time, when I asked my first question. I changed code many times. I found, that no min nor max are not the source of the problem. There is no need in demonstrating of the rest of original code- it is the same for A and B. The difference is only here, in these few lines. And my question was- how could it be- both variants are correct. So you cannot answer to my question. Should I send you the answer or you will think for a while? As for what is pointless or not: advice is only pointless if it isn't heeded. You believe that the debugger shows you every information correctly? It doesn't. It can't. It's physically impossible. Why? Which part is hidden? Pipelines? Debugger demonstrates me all what I need to understand the core of situation. You must work really hard, if you want to cheat (or to trick- whichever word do you prefer) debugger. It happens mostly with self-modified code. I've dealt with optimizers 30 years ago: back then it wasn't to hard to anticipate what it would do, and in C you could often emulate pretty much the same without having to invoke the optimizer at all. meaning well optimized C code ran almost as well in debug mode as it did in release. I've dealt with optimizers 20 years ago, and it got more tricky. Still, well optimized C-code often turned out to be near optimal. I've dealt with optimizers 10 years ago, and the experience was very different: for one, the same optimizations in C code sometimes led to slower code, because it prevented the optimizer from performing extremely sophisticated optimizations that you'd never have thought of. Plus the size of the codebase made it impossible to optimize all of your code in that way anyway. At that point I stopped trying to optimize my C/C++ code by hand. More than strange idea. Hi-level optimization cannot be performed by compiler. Low-level usually yes, but not always. Nowadays, when I check release code that doesn't do the same as debug code, I often find that half the variables aren't on stack, and some others get overwritten at unex
-
I can only recommend to you reread the whole discussion. I do know now, where the problem is. OK, compiler is absolutely stable. No problem with it. But it works incorrectly. It reserves some places in a stack for temporary variables. In fact, these variables stores content of co-processor's registers. Some of such temporary variables overlap (partially or completely) another local variables. It might be no problem- some local variables are visible only within some block, not within the whole procedure. If execution of code leaves some block (part of code within such {} brackets), all variables, declared within this block, becomes inaccessible and their place in a stack may be rewritten by another local variable. But compiler creates exe file, which performs this op even when some local variable is visible and accessible!!! And it happens not only with RECT structure, but with some of other local variables too. I saw this process, when I was running release version under debugger. Look up, where I placed piece of my code. Variable "h" was rewritten at least once. If it is not a compiler's bug, I'm definitely an elefant.
a_matseevsky wrote:
But it works incorrectly.
I suggest you reread my post - pointer bugs can have an impact FAR later in the code.
a_matseevsky wrote:
And it happens not only with RECT structure, but with some of other local variables too.
Don't know how to state this more clearly. Either you have a pointer bug or there is a compiler problem. If the latter then reducing the code will demonstrate it AND changing code far from it and unrelated will NOT impact it. Conversely if the former then you will not be able to reduce it because the code that you are looking at is not the source of the problem.
-
Interesting bit about the size comments. I don't recall ever seeing that - maybe a different setting... I trust that by now you realized that it is hard for us to reproduce the exact situation that led to the problem. I still hold that it's dangerous to deduce anything from optimized code, short of print statements or similar right in the original code: you'll never know just what the compiler did, and why, to optimize your memory footprint and performance. It's difficult to draw correlations from assembler to the original code, and the expectations that come with it. The code you posted doesn't look very complex. About the only optimization I would anticipate is that some of the local variables would be stored in register only, rather than on the stack. But then, optimizers work in mysterious ways - you'll never know what kind of optimization they can come up with until you see the code...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Interesting bit about the size comments. I don't recall ever seeing that - maybe a different setting... Which compiler do you use? I only asked it to generate asm file with source code. All the rest was default settings (Sorry, later I added /Zi to generate debugger's symbols in release version. But it does not affect on generation of asm listing) I trust that by now you realized that it is hard for us to reproduce the exact situation that led to the problem. I do. You have no choice but to trust me (and stop looking where is light!). I still hold that it's dangerous to deduce anything from optimized code, short of print statements or similar right in the original code: you'll never know just what the compiler did, and why, to optimize your memory footprint and performance. It's difficult to draw correlations from assembler to the original code, and the expectations that come with it. But I do know exactly, what compiler does!!! What do you think asm listing exists for? Correlation is very simple and there are no problems with it. No matter, which sort of optimization is in use, resulting exe file must do the same things, and no matter, which optimization was used. The code you posted doesn't look very complex. About the only optimization I would anticipate is that some of the local variables would be stored in register only, rather than on the stack. But then, optimizers work in mysterious ways - you'll never know what kind of optimization they can come up with until you see the code... I saw. And without it I would never find, where the problem is. GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Even Straustrup claims, that there are situation, when goto is useful. Assume you need get out of nested loops... do { do { do { if(something is wrong) goto Skip_loops; } while (cond A) } while(cond B) } while(cond C) Skip_loops:;
-
a_matseevsky wrote:
But it works incorrectly.
I suggest you reread my post - pointer bugs can have an impact FAR later in the code.
a_matseevsky wrote:
And it happens not only with RECT structure, but with some of other local variables too.
Don't know how to state this more clearly. Either you have a pointer bug or there is a compiler problem. If the latter then reducing the code will demonstrate it AND changing code far from it and unrelated will NOT impact it. Conversely if the former then you will not be able to reduce it because the code that you are looking at is not the source of the problem.
There was no pointer bugs at all. I declared no pointers, but the structure- RECT lrct. And some local variables too. Compiler allocated them in a stack and added some temporary variables. In a such way: _lrct$=-212; tv5476=-204; It is a time bomb, which might explode in any time. And it did. That's all. So simple.
-
There was no pointer bugs at all. I declared no pointers, but the structure- RECT lrct. And some local variables too. Compiler allocated them in a stack and added some temporary variables. In a such way: _lrct$=-212; tv5476=-204; It is a time bomb, which might explode in any time. And it did. That's all. So simple.
-
a_matseevsky wrote:
I declared no pointers
You have a C++ application and do not use pointers ANYWHERE in the application? (Again is has NOTHING to do with pointers directly associated with the code where you think the bug is.)
I do not think where the bug is. I know it. I know exactly where variables was incorrectly allocated in stack and which command overwrote data. What are you talking about pointers? I do use them, of course, but they was not the cause. It is pointless to discuss here what might happens, ignoring all available info.
-
I do not think where the bug is. I know it. I know exactly where variables was incorrectly allocated in stack and which command overwrote data. What are you talking about pointers? I do use them, of course, but they was not the cause. It is pointless to discuss here what might happens, ignoring all available info.
-
a_matseevsky wrote:
What are you talking about pointers?
Either you didn't read what I said in my previous replies or didn't understand what I said.
jschell wrote: Either you didn't read what I said in my previous replies or didn't understand what I said. I did. It was you who did not read (or did not understand what he read). Look at quotes from your messages: I want to emphasize again that the pointer bug could be anywhere. The behavior you are seing is a symptom not a cause. Don't know how to state this more clearly. Either you have a pointer bug or there is a compiler problem. If the latter then reducing the code will demonstrate it AND changing code far from it and unrelated will NOT impact it. Conversely if the former then you will not be able to reduce it because the code that you are looking at is not the source of the problem. You have a C++ application and do not use pointers ANYWHERE in the application? (Again is has NOTHING to do with pointers directly associated with the code where you think the bug is.) There are empty words about what might happens. Nothing common with real situation. Compiler placed temporary variable too close to another one and when the tv5476 was used, RECT structure was partially overwritten. So simple. It is no pointer's problem- the compiler's one.
-
jschell wrote: Either you didn't read what I said in my previous replies or didn't understand what I said. I did. It was you who did not read (or did not understand what he read). Look at quotes from your messages: I want to emphasize again that the pointer bug could be anywhere. The behavior you are seing is a symptom not a cause. Don't know how to state this more clearly. Either you have a pointer bug or there is a compiler problem. If the latter then reducing the code will demonstrate it AND changing code far from it and unrelated will NOT impact it. Conversely if the former then you will not be able to reduce it because the code that you are looking at is not the source of the problem. You have a C++ application and do not use pointers ANYWHERE in the application? (Again is has NOTHING to do with pointers directly associated with the code where you think the bug is.) There are empty words about what might happens. Nothing common with real situation. Compiler placed temporary variable too close to another one and when the tv5476 was used, RECT structure was partially overwritten. So simple. It is no pointer's problem- the compiler's one.
a_matseevsky wrote:
I did. It was you who did not read
I read the following which you posted. "but occurred again after some insignificant change in code (which was made far from the procedure, where problem occurred!)" Presumably you do not understand what that statement means in terms of what I said and in terms of what you are claiming.
-
a_matseevsky wrote:
I did. It was you who did not read
I read the following which you posted. "but occurred again after some insignificant change in code (which was made far from the procedure, where problem occurred!)" Presumably you do not understand what that statement means in terms of what I said and in terms of what you are claiming.
jschell wrote:
I read the following which you posted.
"but occurred again after some insignificant change in code (which was made far from the procedure, where problem occurred!)"
Presumably you do not understand what that statement means in terms of what I said and in terms of what you are claiming.I do know. Assume you have a pointer, which points yo some array. Sentence like *(p+k)=a may cause a problem if k is greater than array's size. This is the typical problem, associated with pointers. In my case all was different. What I wrote clearly meant that I had changed the source C++ code, then compiler built executable and the problem disappeared. Then I changed code again, recompiled it and the problem occurred again. That's just what I meant. Where do you see pointers? Moreover, at that very moment when I wrote aforementioned text, I did not know, where the problem was. I only noticed, that code worked correctly when I had excluded max and min. But problem occurred again! The most remarkable was the fact that I did not change suspicious procedure- changes had made far from it. But if one single line of code has been changed, compiler compiles the whole file with this line of code. I got compiler to build release with debug info and ran procedure under debugger. This was how I found where the problem is- I noticed that very command, which overwrote RECT structure and immediately found, why it happened. That's all.
-
jschell wrote:
I read the following which you posted.
"but occurred again after some insignificant change in code (which was made far from the procedure, where problem occurred!)"
Presumably you do not understand what that statement means in terms of what I said and in terms of what you are claiming.I do know. Assume you have a pointer, which points yo some array. Sentence like *(p+k)=a may cause a problem if k is greater than array's size. This is the typical problem, associated with pointers. In my case all was different. What I wrote clearly meant that I had changed the source C++ code, then compiler built executable and the problem disappeared. Then I changed code again, recompiled it and the problem occurred again. That's just what I meant. Where do you see pointers? Moreover, at that very moment when I wrote aforementioned text, I did not know, where the problem was. I only noticed, that code worked correctly when I had excluded max and min. But problem occurred again! The most remarkable was the fact that I did not change suspicious procedure- changes had made far from it. But if one single line of code has been changed, compiler compiles the whole file with this line of code. I got compiler to build release with debug info and ran procedure under debugger. This was how I found where the problem is- I noticed that very command, which overwrote RECT structure and immediately found, why it happened. That's all.
a_matseevsky wrote:
Where do you see pointers?
Explaining it again... - Pointer errors can show up far from the code where the bug actually is. - Pointer errors do NOT automatically show up. An application can have a pointer error for years and run without problem. - Changing code changes the execution path. BECAUSE of that a pointer error that previously did not impact the application can now impact the application. Feel free to explain yourself, excluding pointer errors, why the code you change some where completely different is now causing this compiler bug to show up now.
-
a_matseevsky wrote:
Where do you see pointers?
Explaining it again... - Pointer errors can show up far from the code where the bug actually is. - Pointer errors do NOT automatically show up. An application can have a pointer error for years and run without problem. - Changing code changes the execution path. BECAUSE of that a pointer error that previously did not impact the application can now impact the application. Feel free to explain yourself, excluding pointer errors, why the code you change some where completely different is now causing this compiler bug to show up now.
I explained you point by point where the problem is and how it occurred. Despite of it, you repeat your ideas about pointers. It is rather ridiculous, because I have the source code, generated asm file and result of disassembling of exe file (which can be compared with the asm file, generated by compiler). Finally, I can (and I did) run my exe file under debugger. You have no such options at all. Under such circumstances it is very strange idea to try to explain me not what actually happened, but what might happen!