Browse thread
Is it a bug or just ordinary floating point differences?
- Richard Jones
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2008-11-17 (10:23) |
From: | Richard Jones <rich@a...> |
Subject: | Is it a bug or just ordinary floating point differences? |
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