From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 513D77EEBF for ; Mon, 29 Jun 2015 19:50:29 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of rich@annexia.org) identity=pra; client-ip=80.68.91.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of rich@annexia.org designates 80.68.91.176 as permitted sender) identity=mailfrom; client-ip=80.68.91.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@furbychan.cocan.org) identity=helo; client-ip=80.68.91.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="postmaster@furbychan.cocan.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CLDQBrhJFV/7BbRFBBGoMRHwQxX4JQihmeEAkBAQUBBX+SfAyHNUwBAQEBAQGBC0EFg2E0AYECEyEFKIhnAQg6ojCmPIYcPYcsgXxsghcMQR2BFAWRJ4JdAYRYhnuBfYt5ikYmgVWCJj0xAQGCRgEBAQ X-IPAS-Result: A0CLDQBrhJFV/7BbRFBBGoMRHwQxX4JQihmeEAkBAQUBBX+SfAyHNUwBAQEBAQGBC0EFg2E0AYECEyEFKIhnAQg6ojCmPIYcPYcsgXxsghcMQR2BFAWRJ4JdAYRYhnuBfYt5ikYmgVWCJj0xAQGCRgEBAQ X-IronPort-AV: E=Sophos;i="5.15,371,1432591200"; d="scan'208";a="138301934" Received: from furbychan.cocan.org ([80.68.91.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 29 Jun 2015 19:50:28 +0200 Received: from rich by furbychan.cocan.org with local (Exim 4.84) (envelope-from ) id 1Z9dCM-0000cT-Sw for caml-list@inria.fr; Mon, 29 Jun 2015 18:50:26 +0100 Date: Mon, 29 Jun 2015 18:50:26 +0100 From: "Richard W.M. Jones" To: caml-list@inria.fr Message-ID: <20150629175026.GE31462@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) Subject: [Caml-list] =?ISO-8859-1?Q?ppc64le_behaviour_of_Int64=2Emin=5Fint?= =?ISO-8859-1?Q?_=F7_-1?= Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1236615 OCaml expects Int64.min_int ÷ -1 to overflow and wrap around (resulting in Int64.min_int). There is also a test case in the test suite for this. See this previously fixed bug: http://caml.inria.fr/mantis/view.php?id=5513 The compiler seems to cater for the case where an overflow in the division throws an exception. Unfortunately ppc64le does neither of these things: On ppc64le the result of the computation is explicitly undefined, it sets a flag bit (OV), but it doesn't throw an exception. [See page 76 of https://www.power.org/wp-content/uploads/2013/05/PowerISA_V2.07_PUBLIC.pdf ] I wonder if there is a way to tell the compiler about this? I could add a conditional branch, but that would make the expansion of every Int64.div and Int64.rem quite large (but maybe that doesn't matter as these functions are going to be slow anyway?) Suggestions welcome ... Rich. -- Richard Jones Red Hat