help requested with long double issue on 32-bit FreeBSD

[Steve Kargl]

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