From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Test failure of ilmbase-2.2.0 on i686-linux (testBoxAlgo.cpp) Date: Tue, 08 Dec 2015 15:36:09 -0500 Message-ID: <87si3cy8xy.fsf@netris.org> References: <20151208053857.GA29923@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6Ozp-0005Vy-9Q for guix-devel@gnu.org; Tue, 08 Dec 2015 15:36:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6Ozm-0002ZZ-3J for guix-devel@gnu.org; Tue, 08 Dec 2015 15:36:25 -0500 In-Reply-To: <20151208053857.GA29923@jasmine> (Leo Famulari's message of "Tue, 8 Dec 2015 00:38:57 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Leo Famulari Cc: guix-devel@gnu.org, openexr-devel@nongnu.org, 22049@debbugs.gnu.org [added 22049@debbugs.gnu.org to the CC list] Leo Famulari writes: > Greetings from Guix! [0] > > We're having trouble building ilmbase-2.2.0 for the i686 architecture on > Linux, with gcc-4.9.3. > > The build process fails during testing. Specifically, it fails > testBoxAlgo, like this: > > ImathTest: testBoxAlgo.cpp:892: void {anonymous}::boxMatrixTransform(): A= ssertion `b21 =3D=3D b2' failed. > /gnu/store/isxqjfaglyfsbcv75y8qbqbph8v28ykr-bash-4.3.39/bin/bash: line 5:= 4565 Aborted ${dir}$tst > > On our mailing list, this was suggested as the nature of the problem > [1]: > On Mon, Nov 30, 2015 at 10:14:49PM +0200, Ludovic Court=C3=A8s wrote: >> Right. This sounds very much like a rounding issue, whereby the >> epsilon in floating-point number comparisons is to strict for 32-bit >> machines. Given that ilmbase builds successfully in Guix on x86_64, mips64el, and armhf, and only fails on i686, I believe that Ludovic's suggestion is right on the mark. The issue is that the x87 instruction set (used on 32-bit Intel systems without SSE) uses 80-bit double-extended precision internally. When these 80-bit results are later converted to 64-bit doubles, they are rounded a second time. This "double rounding" results in larger round-off errors than would occur when rounding only once to 64-bit doubles, as is done when using x86_64, SSE2, or other architectures. For more on this, see: https://en.wikipedia.org/wiki/Rounding#Double_rounding Quoting from that page: Some computer languages and the IEEE 754-2008 standard dictate that in straightforward calculations the result should not be rounded twice. This has been a particular problem with Java as it is designed to be run identically on different machines, special programming tricks have had to be used to achieve this with x87 floating point.[1][2] [1] Samuel A. Figueroa (July 1995). "When is double rounding innocuous?". ACM SIGNUM Newsletter (ACM) 30 (3): 21=E2=80=9325. doi:10.1145/221332.221334. [2] Roger Golliver (October 1998). "Efficiently producing default orthogonal IEEE double results using extended IEEE hardware". Intel. Hope this helps, Mark