Serious bug in Intel ICD

I’m almost 100% sure I did see an address to an Intel rep. here not too many moons ago, but as I didn’t find it during a search I post this info in hopes that person sees it.

The Intel ICD 14.15 for 915 has a very serious bug. Calling glShadeModel, but other functions are most likely affected too, it corrupts ecx.

The specifics for glShadeModel is that the call goes to opengl32.dll, that jumps to iglicd32.dll, function 0x10172a70, that establishes an ebp-frame, takes two conditional jumps, and then at address 0x10172aeb, without saving ecx on the stack:
mov ecx, esi
Blam!

I don’t think I have to go into details about the effect, especially if you are using C++ where many compiler uses ecx as the ‘this’ pointer.

While on the subject of quality, I’d also like to take the opportunity to point out (both to Intel and ATI), that you should consider rebasing your DLL’s a little better. Intel’s ICD isn’t rebased at all (meaning the loader most likely needs to relocate it = slower and consumes more memory) and ATI (at least for Cat 5.3), while they have displayed good intentions, the ICD has become so large that the address space that once worked when the DLL was smaller (0x69000000), is occupied by the systems opengl32.dll (@0x69510000 on NT5sp4), and the ICD is therefore always relocated by the loader.

I do not claim to be an expert, but I always thought you could not rely on the value of ecx being saved?

A quick look here:
http://msdn.microsoft.com/library/defaul…conventions.asp

and it seems ESI, EDI, EBX, and EBP registers are the only ones that need saving?

But like I said I am no ASM expert…

You’re right. The error was all mine. Sorry for the wasted time and space.