IVF odd behaviour: subroutine vs function returning floating point number 
Author Message
 IVF odd behaviour: subroutine vs function returning floating point number

About two weeks ago, I discovered a weird bug in my program. Initially
I thought
it was related to the C++ routines. It took me 4 days to finally find
the
culprit of the problem. During my program start up, I have do call the
LAPACK routine DLAMACH to initialize it so that my multi-threaded
program
can run without crashing. I forgot that it is a function returning a
double
precision number and treated it as a subroutine.

I didn't run into any problems when my program is combined with Windows

user interface. Suddenly it showed up after I removed GUI and the
behaviour
became unpredictable. I started reading how Microsoft returns a float.
It turns out that the floating point number stays on the FPU stack
contrary
to what I thought. I figured that it might have left the stack unwound.

But the problem only occurs with IVF not CVF even though the calling
conventions follow CVF. Perhaps the behaviour of CVF should also be
undefined
as well?



Sat, 15 Dec 2007 11:35:38 GMT  
 IVF odd behaviour: subroutine vs function returning floating point number

Quote:
>I didn't run into any problems when my program is combined with Windows

>user interface. Suddenly it showed up after I removed GUI and the
>behaviour
>became unpredictable. I started reading how Microsoft returns a float.
>It turns out that the floating point number stays on the FPU stack
>contrary
>to what I thought. I figured that it might have left the stack unwound.

>But the problem only occurs with IVF not CVF even though the calling
>conventions follow CVF. Perhaps the behaviour of CVF should also be
>undefined
>as well?

The floating point stack use is not connected to the "calling convention"
choices of STDCALL and C.  If you call a function that returns a value on the
FP stack, the caller must remove it from the stack, which means that the
caller must know that it is a function returning the appropriate type.
Failure to do so can lead to unpredictable behavior.  This is universally true
across all compilers and languages which use the X87 floating point stack.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel fortran Support
  http://developer.intel.com/software/products/support/



Sat, 15 Dec 2007 21:44:52 GMT  
 IVF odd behaviour: subroutine vs function returning floating point number
I think in a way, it is. The behavriour would have been completely
different if
return value was stored in some registers in CPU instead of FPU. I
wasn't implying
that only STDCALL would cause the problem. I am only puzzled why we
never
had problems with CVF (or IFC). I guess it was just luck.


Sun, 16 Dec 2007 07:32:45 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. number representations (was: even vs. odd numbers)

2. Getting a floating point number from a float-object

3. fixed point vs floating point

4. fixed point vs floating point

5. fixed point vs floating point

6. Floating Point vs Fixed Point

7. An alternative to floating point (was Re: Floating point non-exactness)

8. IBM 370 Floating point to IEEE floating point

9. floating-point subroutine

10. Floating Point: Binary Shift Subroutine

11. IEEE specials returned from floating point operations

12. even vs. odd numbers

 

 
Powered by phpBB® Forum Software