From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 30EAEBC8E for ; Sun, 27 Feb 2005 11:13:22 +0100 (CET) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j1RADL89005239 for ; Sun, 27 Feb 2005 11:13:21 +0100 X-T2-Posting-ID: 2IIuXFmkcTpj3lKEFKW25A== Received: from [83.176.173.29] (HELO poincare) by mailfe03.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 111103684; Sun, 27 Feb 2005 11:13:20 +0100 Received: from poincare ([127.0.0.1] helo=localhost ident=trch) by poincare with esmtp (Exim 3.36 #1 (Debian)) id 1D5LQK-0001YM-00; Sun, 27 Feb 2005 11:13:16 +0100 Date: Sun, 27 Feb 2005 11:13:14 +0100 (CET) Message-Id: <20050227.111314.133428119.Christophe.Troestler@umh.ac.be> To: jon@jdh30.plus.com Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] [Bug] Different behavior bytecode/nativecode From: Christophe TROESTLER In-Reply-To: <200502270444.51192.jon@jdh30.plus.com> References: <20050227.011343.11780601.Christophe.Troestler@umh.ac.be> <200502270444.51192.jon@jdh30.plus.com> Organization: Universite de Mons-Hainaut (http://math.umh.ac.be/an/) X-Spook: Manfurov BCCI Audiotel CIA encryption Geraldton White House event security CBNRC IDEA X-Blessing: Om Ah Hum Vajra Guru Pema Siddhi Hum X-Operating-System: GNU/Linux (http://www.linux.org/) X-Mailer-URL: http://www.mew.org/ X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 42219D41.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 bug:01 bytecode:01 nativecode:01 christophe:01 troestler:01 christophe:01 troestler:01 umh:01 wrote:01 ocamlc:01 ocamlopt:01 ocamlopt:01 ocamlc:01 caml-list:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Sun, 27 Feb 2005, Jon Harrop wrote: > > The problem is the conflict of interests between having ocamlc and > ocamlopt behave identically, and having ocamlopt-compiled code > achieve good performance. In floating-point code, ocamlopt can > sometimes generate slightly different results from ocamlc. > http://caml.inria.fr/caml-list/1147.html Thanks for the pointer. > Specifically, your code is numerically unstable Yes, I know about this but was blind-sighted by the different results of the two compilers... :( (I checked the values of "cr" where identical but not with enough precision...) > ocamlopt is generating x86 code which is partly performed in 80-bit > registers and partly stored in 64-bit memory locations Are there general rules about this: does a "let" necessarily put the result into 64-bit memory (as an assignment in C does) or is it more complicated (e.g. due to inlining)? Thanks for quickly finding my mistake! Regards, ChriS