[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#49659] [PATCH core-updates] gnu: guile: Fix failing tests on i686-l
From: |
Ludovic Courtès |
Subject: |
[bug#49659] [PATCH core-updates] gnu: guile: Fix failing tests on i686-linux. |
Date: |
Tue, 20 Jul 2021 15:55:49 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi!
Maxime Devos <maximedevos@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’.