Compiler bug? (10.0.025)

[Alexey_T_]

Working on one project i've found strange bug: debug version of the project crashed with "Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call".

So, i've found out that code(same fault):

[cpp]
void t2(int a)
{
return;
}
void t1()
{
t2(10);
__try
{
}
__except(1)
{
}
}
int main()
{
t1();
return 0;
}
[/cpp]

Compiler:
Intel(R) C++ Compiler for applications running on IA-32, Version 10.0 Build 20070426 Package ID: W_CC_P_10.0.025

Command line:
icl /c /Od /RTC1 /MDd /Gd main.cpp
xilink main.obj

After some diggin, i've found out following:
1. Call t1
2. Allocate all needed memory on stack
3. Save esp
4. Call t2 (pass arguments through stack)
5. Free stack memory ( arguments to t2() )
6. Restore esp
7. Compare esp, ebp // !!!! Houston, we've got troubles!

Asm listing is the following(only faulty code):
[plain]
push -1
push OFFSET FLAT: _try_info_pack0
push OFFSET FLAT: __except_handler3
push eax
sub esp, 18h
mov DWORD PTR [ebp - 18h], esp
add esp, 0
call t2
pop ecx
mov esp, DWORD PTR [ebp - 18h]
add esp, 24h
cmp ebp, esp
call __RTC_CheckEsp
[/plain]

Sample is the following:
[plain]
push eax;
mov dword ptr[ebp - 18h], esp;
pop eax;
mov esp, dword ptr[ebp - 18h];
cmp esp, ebp; // !!!!
[/plain]

Solution is rather simple: add this to the beginning of the t1():
[cpp]
__asm
{
nop;
}
[/cpp]

There is no crash after that, asm listings shows us correct code(memory allocates just before calling t1, frees just after):
[plain]
push -1
push OFFSET FLAT: _try_info_pack0
push OFFSET FLAT: __except_handler3
push eax
sub esp, 14h
mov DWORD PTR [ebp - 18h], esp
push edi
call t2
pop ecx
mov esp, DWORD PTR [ebp - 18h]
add esp, 24h
cmp ebp, esp
call __RTC_CheckEsp
[/plain]

So, sample is the following:

[plain]
mov dword ptr[ebp - 18h], esp;
push eax;
pop eax;
mov esp, dword ptr[ebp - 18h];
cmp esp, ebp; // Good!
[/plain]

So, is it Compiler bug?

P.S.
Code crashes while calling any function t2() from t1(), if arguments to t2() were passed through stack.

P.P.S.
Compiling with version 11.1.035 solves problem, so i might think that it is compiler bug.

[SergeyKostrov]

In case of version 10.0 Update 025 you need to consider a workaround ( already suggested ) if a similar functionality is used in some project because there is no way it could be fixed. It makes sense to check if more updates are available for that version of Intel C++ compiler.