Just wanted to share with you that I have found a bug in VC++ ver 6 service pack 5 using the processor pack. I guess a lot of you coders are using this in OpenGL programs.
A large project I am working on confirmed that with the processor pack option there are several occasions when the compiler generates faulty code for the stack management and the registers esp and esi wich results in failure on the _chkesp routine. Without the processor pack these bugs doesn’t occur.
I seem to remember something like this. Long time since I did inline SSE. I think I had misused some instruction or…
What 's your code?
V-man
The project I am working on has about 1.500.000 lines of code and we found about 20 procedures that worked ok without the processor pack but with the pack added the code get corrupt esi reg values at exit. This indicates that the errors doesn’t occur very often.
VC can generate a stack check on each call to a procedure that checks the value of esp before and after the call and trows a message box in your face if esp and esi values doesn’t match after the call to indicate your stack is wrong. This check is done by an automatic inserted call to _chkesp at each exit of the procedure call.
We get this error even without using any SIMD coding at all, so the conclusion is that there is something wrong with the linker or compiler.
We get this error even without using any SIMD coding at all, so the conclusion is that there is something wrong with the linker or compiler.
If you KNOW which functions fail, it should be excruciatingly easy to just disassemble the same function compiled with the regular compiler, and with the processor pack compiler, and compare results.
We never ended up using the Processor Pack, because it would randomly Internal Compiler Error on perfectly legit C++ code (yes, even when building from scrath) and what little SIMD we write, we might as well stick to nasm (which is also portable).
I had “funny” debugging session after I upgraded Borland C++ Builder from 5 to 6. The compiler generated function that returned its result in ecx(!), while caller code assumed the result was in eax as usual. When i enabled inlining option (which is disabled by default when project is in ‘Debug’ mode) the problem magically disappeared.
Another situation where I had this kind of problem was with dll function imports. The export were exported with cdecl while import assumed stdcall.
So you dont have to worry about 1.5 MLocks of code, just the thousands of functions you use 
Jwatte is right, when the error is cought, its when the offending function completes execution and returns.
V-man
I wrote my own macros for the SIMD intrinsics and now it works ok…
Compared to VC7, VC6 is really outdated.
Not only it’s buggy, has serious memory leaks and doesn’t respect the C++ standard.
I hardly understand why someone would still use VC6 instead of VC7 or GCC.
PS: I always wondered how some project could go up to 1.5 millions lines of code. 
What I don’t like about the Microsoft environment is that it doesn’t scale.
We have a project with about 300 libraries and a few million lines of code. Most of these get statically linked into a single executable. All of the “codeview” and browser stuff just won’t work right. Turning on any of the auto-info options means that everytime you type “->” or “.” you get a three-second pause (this is on 2 GHz class development machines).
What’s worse: when you have a project of this size, just quitting MSDEV will make it hang, and eventually segfault. So we just save all files and kill it with task manager.
Now, we tried migrating this project to MSDEV version 7. It opened the workspace and said “I need to convert these 300 projects!”. Three hours later, we killed the process, and are staying with version 6 for a while longer.
Microsoft tools are great for small-to-medium size projects, such as custom report generators for a business accounting system, or maybe even a normal-size game, but I think the scalability tops out right around there.
A hint from our project…
Delete .ncb and .opt files regulary
Use precomp headers in one project
Don’t run program from complete project. Start it without debugger and attach a debugger later.
These tricks make larger projects a bit quicker to manage…
Originally posted by jwatte:
What I don’t like about the Microsoft environment is that it doesn’t scale.
Is there an environment that you prefer over the MS solution (for example, Borland)?
Our project isn’t quite as large (1/2-3/4 million lines), but I’d still be interested in other alternatives.