Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Aug 2013 19:42:00 -0700
From:      Steve Kargl <sgk@troutmask.apl.washington.edu>
To:        Zimmermann Paul <Paul.Zimmermann@inria.fr>
Cc:        freebsd-numerics@freebsd.org
Subject:   Re: help requested with long double issue on 32-bit FreeBSD
Message-ID:  <20130810024200.GA62686@troutmask.apl.washington.edu>
In-Reply-To: <E1V7sbp-0008Q6-MC@tarte.loria.fr>
References:  <E1V7sbp-0008Q6-MC@tarte.loria.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 09, 2013 at 09:44:25PM +0200, Zimmermann Paul wrote:
> 
> [this mail was sent on the MPFR list, but Steve Kargl suggested to post it
> also here]
> 
> we need help to investigate an error we get with the development version of
> MPFR on i686-freebsd. The error occurs on the hydra.nixos.org continuous
> integration platform. Unfortunately we don't have direct access to the
> corresponding computer, thus isolating the issue is not easy.
> 
> The error we get can be seen at http://hydra.nixos.org/build/5666171/log/raw.
> Starting from the long double value in 3, and subtracting e=0.25, we get the
> long double value in 4, which is obviously wrong in the last bits:
> 
> 3: d=2.632048527199790448306230411512629530e-01
> 4:  d=1.320485271997904469509776959057489876e-02
>                         ^^^^^^^^^^^^^^^^^^^^
> 
> We believe this is a compiler bug (GCC 4.2.1 was used in this test).
> 
> If you have access to a 32-bit computer under FreeBSD, please could you try
> to compile the development version and run the "tset_ld" test, after doing
> export GMP_CHECK_RANDOMIZE=1376689137?
> 
> If you can reproduce the error, please tell Vincent Lef??vre and myself
> (Vincent.Lefevre at ens-lyon.fr and Paul.Zimmermann at inria.fr); we'll help
> you to isolate the problem (e.g., trying different optimization levels).
> 
> If you can't reproduce (on a 32-bit FreeBSD machine), please tell us too;
> this might indicate the bug was fixed in a later gcc version.

I see the issue on my system.  With a trivial program,

#include <stdio.h>
int
main(void)
{
   long double d, e, r;

   d = 2.632048527199790448306230411512629530e-01L;
   e = 0.25L;
   r = d - e;
   printf("%.25Le\n", d);
   printf(" %.25Le\n", r);
   printf(" %.25Le\n", d - e);
   printf("   32048527199790448306230411512629530\n");
   return (0);
}

I see

% ~/work/bin/gcc -o z a.c && ./z
2.6320485271997906551177948e-01
 1.3204852719979065511779481e-02
 1.3204852719979065511779481e-02
   32048527199790448306230411512629530

I get these results with 4.2.1, 4.6.3, and 4.9.0.

-- 
Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130810024200.GA62686>