Is this a VC7.1 optimizer bug?

[James Edwards]

I'm seeing a problem where with -O2 -Ob2 on, my compiled code loads the
floating point value 1.0f on top of the floating point register stack (ST0),
then calls some functions (which happens to call driver functions in the
kernel), then later when it needs to assign the constant 1.0f to a variable,
it tries to use the value stored in ST0. The only problem is that the 1.0f
value is no longer there, the call into the kernel has set ST0 to float NaN!
Is this a problem with the VC optimizer (incorrectly assuming calls won't
modify the FP stack) or with the kernel call that modifies the FP stack?

[David Lowndes]

>I'm seeing a problem where with -O2 -Ob2 on, my compiled code loads the

floating point value 1.0f on top of the floating point register stack (ST0),
then calls some functions (which happens to call driver functions in the
kernel), then later when it needs to assign the constant 1.0f to a variable,
it tries to use the value stored in ST0. The only problem is that the 1.0f
value is no longer there, the call into the kernel has set ST0 to float NaN!

James,

Do you have a short example that anyone can use to reproduce the
problem?

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[James Edwards]

"David Lowndes" wrote:

I'm seeing a problem where with -O2 -Ob2 on, my compiled code loads the
floating point value 1.0f on top of the floating point register stack (ST0),
then calls some functions (which happens to call driver functions in the
kernel), then later when it needs to assign the constant 1.0f to a variable,
it tries to use the value stored in ST0. The only problem is that the 1.0f
value is no longer there, the call into the kernel has set ST0 to float NaN!

James,

Do you have a short example that anyone can use to reproduce the
problem?

No, and it's unlikely I can make one since the kernel call in question is
NtGdiDrawPrimitives2, which calls into graphics driver code which of course
is video-card specific, and the problem only occurs with my rather large
dataset, although it is 100% reproducible. I was just hoping some
assembly/windows kernel guru would know if I should be pointing the finger of
blame at the compiler or the kernel/driver.

[David Lowndes]

>> Do you have a short example that anyone can use to reproduce the

problem?

No, and it's unlikely I can make one since the kernel call in question is
NtGdiDrawPrimitives2, which calls into graphics driver code which of course
is video-card specific, and the problem only occurs with my rather large
dataset, although it is 100% reproducible.

A quick google on that kernel call you mention shows up nothing, so I
think the hard part is going to be finding someone who's familiar with
that. I don't know where to suggest you find such a person.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq