Re: vs 8 bug ?
"gordon" <gordon@discussions.microsoft.com> wrote in message
news:63C3182B-B837-409A-9B33-886B92B7872B@microsoft.com...
Thank you all for your interest and meaningful replies ...
I should have mentioned in my first post that all optimization is disabled
in both projects ...
After digesting all your replies I must say I still tend toward the view
of
a compiler bug ... Consider the following :
1) Certainly the stack pointer must be restored to the value it had prior
to
any given call after that given call returns ...
2) Clearly, an "optimization" which optimizes away [ esp-8 ] & [esp+8]
means
the called function would not know where to find the parameter passed in
by
the calling function ...
And it bugs me that this optimization is done while you claim optimizations
are off. Have you done a full rebuild?
3) A quick review of the additional code posted in response to Ben's
request
indicates that upon return from the call to "pApuUpdateHWclock" the stack
pointer is indeed restored to its pre-call value ... but, then on the next
call to function "_pApuFubar" the stack is not restored to its pre-call
value
...
4) Now, "_pApuFubar" is simply an alias for the same call to
"pApuUpdateHWclock" ... another name declared which executes the same call
...
5) the only difference between these two calls is the "_asm nop" present
after the first call to "pApuUpdateHWclock" ...
6) finally, this is a very straight forward sequence of function calls,
nothing "tricky" going on at all ... why has the compiler generated code
which allows the stack pointer to drift ever downward ? Doesn't make sense
to
me ...
7) Maybe I am still missing something ... I think I will try Cholo's
pragma
suggestion ...
I know I can be stubborn, but , really, I can't see how re-organizing this
very simple loop can be a valid solution to the issue at hand ... IMHO the
darned loop should work in its present form ...
Given that adding a NOP changes the behavior, I suspect an optimizer bug (or
the dependency system failed to recompile properly)... however optimization
is inhibited for the whole function so it could be anywhere, not just on the
line where you added the NOP to "fix" it.
Is it reasonable to approach one of microsoft's compiler people about this
?
--
gordon
"gordon" wrote:
Hi Forum,
I have some disassembly to post which I think indicates a bug ... if not,
then hopefully one of the gurus here can tell me what I'm doing wrong ...
The scenario here is a .exe making a call to a __declspec( dllexport )
declared c function ... both projects are configured for _cdecl linkage
...
What follows are two dissambly blocks, the first with the ** alleged **
bug,
and the second with what seems to ** fix ** the alleged bug ...
------------------------ "bad" code block
------------------------------------------
pApuUpdateHWclock(fCurrentSimulationTime);
00401266 83 EC 08 sub esp,8
00401269 DD 45 A8 fld qword ptr [ebp-58h]
0040126C DD 1C 24 fstp qword ptr [esp]
0040126F FF 15 E8 D4 47 00 call dword ptr [_pApuUpdateHWclock
(47D4E8h)]
// __asm nop
_pApuFubar(x);
00401275 DD 45 E0 fld qword ptr [ebp-20h]
00401278 DD 1C 24 fstp qword ptr [esp]
.
.
.
--------------------------------"good" code block --------------------
pApuUpdateHWclock(fCurrentSimulationTime);
00401266 83 EC 08 sub esp,8
00401269 DD 45 A8 fld qword ptr [ebp-58h]
0040126C DD 1C 24 fstp qword ptr [esp]
0040126F FF 15 E8 D4 47 00 call dword ptr [_pApuUpdateHWclock
(47D4E8h)]
00401275 83 C4 08 add esp,8
__asm nop
00401278 90 nop
_pApuFubar(x);
00401279 83 EC 08 sub esp,8
0040127C DD 45 E0 fld qword ptr [ebp-20h]
.
.
.
---------------------------------------------------------------------------------------
So, obviously, inserting a nop into the instruction stream has
"corrected"
the stack cleanup issue ...
What gives , gurus ?
Best Regards ,
gordon