English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Is it a bug or just ordinary floating point differences?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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:

    Windows cross-compiler 3.11.0+beta1.

    Windows 32-bit ocamlopt 3.10.2.

    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.


Richard Jones
Red Hat