caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Is it a bug or just ordinary floating point differences?
@ 2008-11-17 10:23 Richard Jones
  2008-11-17 12:23 ` Another example (was: Re: [Caml-list] Is it a bug or just ordinary floating point differences?) Richard Jones
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Jones @ 2008-11-17 10:23 UTC (permalink / raw)
  To: caml-list

I'm tracing a failure in the Calendar test suite when we are compiling
using the OCaml Windows cross-compiler.  It comes down to the
following piece of test code:

----------------------------------------------------------------------
open Printf
let x = 1 * 3600 + 2 * 60 + 3 ;;
printf "minutes = %g\n" (float x /. 60.) ;;
printf "minutes (immediate) = 62.05 is %b\n" ((float x /. 60.) = 62.05) ;;
let m = float x /. 60. ;;
printf "minutes (variable) = 62.05 is %b\n" (m = 62.05) ;;
----------------------------------------------------------------------

When this is compiled using ordinary ocamlopt on a variety of
platforms (32 & 64 bit Linux, and 32 bit Windows), I always get the
following output:

  minutes = 62.05
  minutes (immediate) = 62.05 is true
  minutes (variable) = 62.05 is true

However my Windows cross-compiler (only) prints this:

  minutes = 62.05
  minutes (immediate) = 62.05 is false
  minutes (variable) = 62.05 is true

Interestingly the generated assembly is pretty much identical in all
cases, excepting whitespace and some non-essential syntactic changes:

  http://www.annexia.org/tmp/test_float-i686-crosswin-3.11.0.s
    Windows cross-compiler 3.11.0+beta1.

  http://www.annexia.org/tmp/test_float-i686-win-3.10.2.s
    Windows 32-bit ocamlopt 3.10.2.

  http://www.annexia.org/tmp/test_float-i686-linux-3.08.3.s
    Linux 32-bit ocamlopt 3.08.3.

As an example, try:
  diff -ub test_float-i686-crosswin-3.11.0.s test_float-i686-win-3.10.2.s

There don't seem to be any calls to the stdlib (eg. to caml_compare)
which could cause a difference.

Obviously I'm aware of the difference between storing a floating point
value into a variable versus keeping a (higher precision) immediate
value in an x86 register, but the lack of any difference in the
assembly output makes me suspicious that something else is going on,
and that this could be a bug in the cross-compiler.

Rich.

-- 
Richard Jones
Red Hat


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Another example (was: Re: [Caml-list] Is it a bug or just ordinary floating point differences?)
  2008-11-17 10:23 Is it a bug or just ordinary floating point differences? Richard Jones
@ 2008-11-17 12:23 ` Richard Jones
  2008-11-17 12:26   ` Richard Jones
  0 siblings, 1 reply; 3+ messages in thread
From: Richard Jones @ 2008-11-17 12:23 UTC (permalink / raw)
  To: caml-list


----------------------------------------------------------------------
open Printf ;;
printf "%d\n" (int_of_float (62.05 *. 60.)) ;;
let s = 62.05 *. 60. ;;
printf "%d\n" (int_of_float s) ;;
----------------------------------------------------------------------

Ordinary ocamlopt prints:

  3723
  3723

The cross-compiler prints:

  3722
  3723

The generated assembly is again identical apart from differences which
seem insignificant to me.  Shown below is the diff between the
ocamlopt 3.10.2 for Windows downloaded from caml.inria.fr, and my own
cross-compiler (both running under Wine).

I'm thinking the difference must be somewhere in Wine itself or in the
way that the two compilers initialize the floating point environment,
such as using different rounding modes.

Does anyone have a true Windows version of 3.11.0 that they could
check out the test programs on?

Rich.

--- test_float2-win-3.10.2.s    2008-11-17 12:13:26.000000000 +0000
+++ test_float2-crosswin-3.11.0.s       2008-11-17 12:14:09.000000000 +0000
@@ -26,7 +26,7 @@
        subl    $8, %esp
 L100:
        movl    $_camlTest_float2__2, %eax
-       call    _camlPrintf__printf_364
+       call    _camlPrintf__printf_403
 L101:
        movl    %eax, %ebx
        fldl    L102
@@ -58,7 +58,7 @@
        fstpl   (%eax)
        movl    %eax, _camlTest_float2
        movl    $_camlTest_float2__1, %eax
-       call    _camlPrintf__printf_364
+       call    _camlPrintf__printf_403
 L108:
        movl    %eax, %ebx
        movl    _camlTest_float2, %eax
@@ -88,6 +88,7 @@
 L103:  .double 62.05
        .data
 L102:  .double 60.
+       .data
        .text
        .globl  _camlTest_float2__code_end
 _camlTest_float2__code_end:


-- 
Richard Jones
Red Hat


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Another example (was: Re: [Caml-list] Is it a bug or just ordinary floating point differences?)
  2008-11-17 12:23 ` Another example (was: Re: [Caml-list] Is it a bug or just ordinary floating point differences?) Richard Jones
@ 2008-11-17 12:26   ` Richard Jones
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Jones @ 2008-11-17 12:26 UTC (permalink / raw)
  To: caml-list

On Mon, Nov 17, 2008 at 12:23:31PM +0000, Richard Jones wrote:
> I'm thinking the difference must be somewhere in Wine itself or in the
> way that the two compilers initialize the floating point environment,
> such as using different rounding modes.

>  L103:  .double 62.05
>         .data
>  L102:  .double 60.

Or another difference could be the way the assembler is converting
these constants into binary.  The cross-compiler uses gas from
binutils 2.18.50 (MinGW 20080109 patch).

Rich.

-- 
Richard Jones
Red Hat


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-11-17 12:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-17 10:23 Is it a bug or just ordinary floating point differences? Richard Jones
2008-11-17 12:23 ` Another example (was: Re: [Caml-list] Is it a bug or just ordinary floating point differences?) Richard Jones
2008-11-17 12:26   ` Richard Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).