GNU bug report logs - #49659
[PATCH core-updates] gnu: guile: Fix failing tests on i686-linux.

Previous Next

Full log

Message #8 received at 49659 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 49659 <at> debbugs.gnu.org
Subject: Re: bug#49659: [PATCH core-updates] gnu: guile: Fix failing tests
 on i686-linux.
Date: Tue, 20 Jul 2021 15:55:49 +0200

Hi!

Maxime Devos <maximedevos <at> telenet.be> skribis:

> i586-gnu might have the same issue.

Please add a “Fixes …” line.

> * gnu/packages/guile.scm
>   (guile-3.0)[arguments]<#:configure-flags>: Add
>   "-fexcess-precision=standard" to CFLAGS.

Nitpick: the first two lines can be joined.  :-)

>       (substitute-keyword-arguments (package-arguments guile-2.2)
>         ((#:configure-flags flags ''())
> -        (let ((flags `(cons "--enable-mini-gmp" ,flags)))
> +        ;; -fexcess-precision=standard is required when compiling for
> +        ;; i686-linux, otherwise "numbers.test" will fail.
> +        (let ((flags `(cons* "CFLAGS=-g -O2 -fexcess-precision=standard"
> +                              "--enable-mini-gmp" ,flags)))

Yay!  Questions:

  1. Should we make it conditional on
       (or (string-prefix? "i686-" %host-type)
           (string-prefix? "i586-" %host-type))
     ?  (I wonder why armhf-linux doesn’t have the same problem.)

  2. Is there any downside to compiling all of libguile with this flag?

  3. Do we have a clear explanation of why ‘-fexcess-precision=fast’
     (the default) would lead to failures in ‘numbers.test’?

I looked at the GCC manual (info "(gcc) Optimize Options") and at links
you provided earlier on IRC, but I can’t really explain how this would
lead those tests to fail: <https://issues.guix.gnu.org/49368>.

I added a ‘printf’ call in ‘scm_i_inexact_floor_divide’, which is where
it all happens:

--8<---------------cut here---------------start------------->8---
static void
scm_i_inexact_floor_divide (double x, double y, SCM *qp, SCM *rp)
{
  if (SCM_UNLIKELY (y == 0))
    scm_num_overflow (s_scm_floor_divide);  /* or return a NaN? */
  else
    {
      double q = floor (x / y);
      double r = x - q * y;
      printf ("%s x=%f y=%f x/y=%f floor(x/y)=%f q=%f r=%f\n", __func__,
	      x, y, x/y, floor (x/y), q, r);
      *qp = scm_i_from_double (q);
      *rp = scm_i_from_double (r);
    }
}
--8<---------------cut here---------------end--------------->8---

I get this:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (euclidean/ 130. (exact->inexact 10/7))
scm_i_inexact_floor_divide x=130.000000 y=1.428571 x/y=91.000000 floor(x/y)=90.000000 q=90.000000 r=1.428571
$1 = 90.0
$2 = 1.4285714285714257
--8<---------------cut here---------------end--------------->8---

So it’s really ‘floor’ that’s messing up somehow.

Perhaps we have to just accept it, use the flag, and be done with it,
but that’s frustrating.

Thoughts?

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.