- Mon 20 Jul 13:27 +0200
- Lon 20 Jul 15:55 +0200
- Mon 20 Jul 18:55 +0200
- Eon 20 Jul 20:22 +0200
- Lon 20 Jul 22:51 +0200
- Mon 20 Jul 23:34 +0200
- Lon 21 Jul 15:49 +0200
- Mon 21 Jul 16:50 +0200
- Lon 23 Jul 11:07 +0200
- Mon 23 Jul 11:27 +0200
- Ton 26 Jul 01:52 +0200

- 5 participants
- Thiago Jung Bauermann
- Efraim Flashner
- Ludovic Courtès
- Maxime Devos
- Mathieu Othacehe

- Owner
- unassigned

- Severity
- normal

M

(address . guix-patches@gnu.org)(name . Maxime Devos)(address . maximedevos@telenet.be)

20210720112712.25905-1-maximedevos@telenet.be

i586-gnu might have the same issue.

* gnu/packages/guile.scm (guile-3.0)[arguments]<#:configure-flags>: Add "-fexcess-precision=standard" to CFLAGS.--- gnu/packages/guile.scm | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)

* gnu/packages/guile.scm (guile-3.0)[arguments]<#:configure-flags>: Add "-fexcess-precision=standard" to CFLAGS.--- gnu/packages/guile.scm | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)

L

(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 49659@debbugs.gnu.org)

871r7tks2i.fsf@gnu.org

Hi!

Maxime Devos <maximedevos@telenet.be> skribis:

Maxime Devos <maximedevos@telenet.be> skribis:

Please add a “Fixes …” line.

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

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 linksyou provided earlier on IRC, but I can’t really explain how this wouldlead those tests to fail: https://issues.guix.gnu.org/49368.

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

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 linksyou provided earlier on IRC, but I can’t really explain how this wouldlead those tests to fail: https://issues.guix.gnu.org/49368.

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

I get this:

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’.

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

Thoughts?

Ludo’.

M

(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 49659@debbugs.gnu.org)

ca331c5fb87a4d0697c5282e5452e0e0eaae6424.camel@telenet.be

Ludovic Courtès schreef op di 20-07-2021 om 15:55 [+0200]:

I didn't find the bug report.

Rather, (target-x86-32?). target-x86-32? also recognises "i486-linux-gnu"even though that's not a ‘supported’ cross-target.

AFAIK floats & doubles on arm don't have excess precision.

Floating-point numbers are either 32-bit or 64-bit,unlike in x86, where the floating-point registers are 80-bitbut (sizeof) double==8 (64 bits).

(I'm ignoring MMX, SSE and the like.)

I don't know any architectures beside x86 which have excess precision."-fexcess-precision=standard" should be harmless on architecturesthat don't have excess precision.

I'd make it unconditional, but conditional on x86-target? should workfor all ‘supported’ targets in Guix.

Floating-point numbers are either 32-bit or 64-bit,unlike in x86, where the floating-point registers are 80-bitbut (sizeof) double==8 (64 bits).

(I'm ignoring MMX, SSE and the like.)

I don't know any architectures beside x86 which have excess precision."-fexcess-precision=standard" should be harmless on architecturesthat don't have excess precision.

I'd make it unconditional, but conditional on x86-target? should workfor all ‘supported’ targets in Guix.

I searched with "git grep -F double" and "git grep -F float".Floating-point arithmetic doen't seem to be used much outside numbers.c.

There's vm-engine.c, but the results of the calculations are writtento some (stack?) memory (not a register), so the excess precisionwould be thrown away anyway, so I don't expect a slow-down.

No code appears to be relying on excess precision.

There's vm-engine.c, but the results of the calculations are writtento some (stack?) memory (not a register), so the excess precisionwould be thrown away anyway, so I don't expect a slow-down.

No code appears to be relying on excess precision.

The problem I think is that the rounding choices made in scm_i_inexact_floor_dividemust be consistent with those made in scm_i_inexact_floor_quotientand scm_i_inexact_floor_remainder(There are tests testing whether the results agree.)

"-fexcess-precision=standard" reduces the degrees of freedom GCC hasin choosing when to round, so it is more likely the rounding choicescoincide? It's only an untested hypothesis though.

FWIW, I think this line:

/* in scm_i_inexact_floor_remainder */ return scm_i_from_double (x - y * floor (x / y));

should be (for less fragility in case GCC changes its optimisations andregister allocation / spilling)

/* in scm_i_inexact_floor_remainder */ return scm_i_from_double (x - y * (double) floor (x / y));

even then, there's no guarantee the rounding choices for x/yare the same in scm_i_inexact_floor_divide, scm_i_inexact_floor_remainderand scm_i_inexact_floor_quotient.

"-fexcess-precision=standard" reduces the degrees of freedom GCC hasin choosing when to round, so it is more likely the rounding choicescoincide? It's only an untested hypothesis though.

FWIW, I think this line:

/* in scm_i_inexact_floor_remainder */ return scm_i_from_double (x - y * floor (x / y));

should be (for less fragility in case GCC changes its optimisations andregister allocation / spilling)

/* in scm_i_inexact_floor_remainder */ return scm_i_from_double (x - y * (double) floor (x / y));

even then, there's no guarantee the rounding choices for x/yare the same in scm_i_inexact_floor_divide, scm_i_inexact_floor_remainderand scm_i_inexact_floor_quotient.

> 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.>

I dunno if 'floor' is broken. Let me explain why this output is possible for awell-implemented 'floor':

I want to note that printf("%f", floor(x/y))can display 16 different strings:

GCC can choose to round 'x' and/or 'y' by moving it from a register to stack memory. (doesn't apply here I think because SCM values discard the excess precision)

GCC can choose to round the result of x/y (same reasons)

GCC can choose to round the result of floor(x/y) (same reasons)

Likewise, printf("%f", x/y) can display 8 different strings, and the roundingchoices may be different from those made for printf("%f", floor(x/y)).

So this inconsistency (x/y=91.00... > 90.00 = floor(x/y)) doesn't reallysurprise me. A more concrete scenario: suppose the CPU is configured to roundupwards, and 'floor' is a mapping between extended-precision floating-point numbers.

Let 'x' and 'y' be two floating-point numbers, such that:

(1) the mathematical value of 'x/y' is slightly less than 91 (2) 'x/y' when calculated in extended precision is slightly less than 91. Denote this approximation as F1. (3) 'x/y' when calculated in double precision is 91 (or slightly larger) (due to the ‘rounding upwards’ mode, in ‘rounding downwards’ it might have been slightly less than 91 as in (2)) Denote this approximation as F2.

Then [floor(x/y)=] floor(F1)=floor(90.999...)=90.0,and [x/y=] F2=91.0, thus we seemingly have x/y >= 1 + floor(x/y),even though that's mathematically nonsense.

Thus, by choosing when to round (in-)appropriately, it is possible (on x86)that printf("x/y=%f, floor(x/y)=%f",x/y,floor(x/y)) will output "x/y=91.0 floor(x/y)=90.0".

(Please tell if I made an error somewhere.)

Greetings,Maxime

I want to note that printf("%f", floor(x/y))can display 16 different strings:

GCC can choose to round 'x' and/or 'y' by moving it from a register to stack memory. (doesn't apply here I think because SCM values discard the excess precision)

GCC can choose to round the result of x/y (same reasons)

GCC can choose to round the result of floor(x/y) (same reasons)

Likewise, printf("%f", x/y) can display 8 different strings, and the roundingchoices may be different from those made for printf("%f", floor(x/y)).

So this inconsistency (x/y=91.00... > 90.00 = floor(x/y)) doesn't reallysurprise me. A more concrete scenario: suppose the CPU is configured to roundupwards, and 'floor' is a mapping between extended-precision floating-point numbers.

Let 'x' and 'y' be two floating-point numbers, such that:

(1) the mathematical value of 'x/y' is slightly less than 91 (2) 'x/y' when calculated in extended precision is slightly less than 91. Denote this approximation as F1. (3) 'x/y' when calculated in double precision is 91 (or slightly larger) (due to the ‘rounding upwards’ mode, in ‘rounding downwards’ it might have been slightly less than 91 as in (2)) Denote this approximation as F2.

Then [floor(x/y)=] floor(F1)=floor(90.999...)=90.0,and [x/y=] F2=91.0, thus we seemingly have x/y >= 1 + floor(x/y),even though that's mathematically nonsense.

Thus, by choosing when to round (in-)appropriately, it is possible (on x86)that printf("x/y=%f, floor(x/y)=%f",x/y,floor(x/y)) will output "x/y=91.0 floor(x/y)=90.0".

(Please tell if I made an error somewhere.)

Greetings,Maxime

E

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

(name . Ludovic Courtès)(address . ludo@gnu.org)

YPcUaWxhYMebiTIa@3900XT

On Tue, Jul 20, 2021 at 03:55:49PM +0200, Ludovic Courtès wrote:

I'd also like to mention that this bug doesn't show up on 32-bit powerpc.

-- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנרGPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351Confidentiality cannot be guaranteed on emails sent or received unencrypted

-- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנרGPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351Confidentiality cannot be guaranteed on emails sent or received unencrypted

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmD3FGkACgkQQarn3Mo9g1G9uA/6AyR1YqeiM2VX+l6HJBNZRtnldPhrRqA9Z8EnWbiJ56UBKuOxXbVE5Bw+DydR7CeDlbDNmKR8/HBtERuqrCni2+lAq/mnwaLdZGx5cIH1Zl/E60o0wT/trKmITchh3QCYBvoDhKF14XVRLHuu4nsZesJ7xLAZpNNpP+24CSl6kYP3flmJsHyzILCN4j6OtRkJZwo3cbYNolGKmd8BLMuPukWNjDBJHzFUglpE/HUkTK5XQZH0yJUxqQV5zTEy+Na/vOBltUy9xEljHF5Cz9Z1EAUxwBkXESow7E+LTdh1TaCw/NyhTs+xzVlUqNOlcsjKE5N55j+2E514v/mRn/VxPT2Ol2yznxID0UOpUg12z2t0iPPNvD27/t47Cqd1brxr6Xf6vl7qnDWIiRePYcg/xjlmLmoX4w6Pu5XU9d8wnoh6HE/k1cbqCph31a4tPfecf+CpMZ8P92t+PdM2ULsY3REGRYLF3NbkRitOjzu4fTCbHkBUYduh42s2tsdsJ09mBnACWnaZw+lhJlAMietw5wc7mMovQM0U2s9vnP0KMHe0URDw/FUKs/kwI5M4sAYzKEOJ0KabruQv1bJMFMsF+2MrUbFr2Sw/L7gUt/WZxOLaTqiBTtWsgPGeOZKbu7i7xkyYoONCjrNLEHPsgRWV4A9gP8jjdx74DmngzHwyaiA==YOl4-----END PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmD3FGkACgkQQarn3Mo9g1G9uA/6AyR1YqeiM2VX+l6HJBNZRtnldPhrRqA9Z8EnWbiJ56UBKuOxXbVE5Bw+DydR7CeDlbDNmKR8/HBtERuqrCni2+lAq/mnwaLdZGx5cIH1Zl/E60o0wT/trKmITchh3QCYBvoDhKF14XVRLHuu4nsZesJ7xLAZpNNpP+24CSl6kYP3flmJsHyzILCN4j6OtRkJZwo3cbYNolGKmd8BLMuPukWNjDBJHzFUglpE/HUkTK5XQZH0yJUxqQV5zTEy+Na/vOBltUy9xEljHF5Cz9Z1EAUxwBkXESow7E+LTdh1TaCw/NyhTs+xzVlUqNOlcsjKE5N55j+2E514v/mRn/VxPT2Ol2yznxID0UOpUg12z2t0iPPNvD27/t47Cqd1brxr6Xf6vl7qnDWIiRePYcg/xjlmLmoX4w6Pu5XU9d8wnoh6HE/k1cbqCph31a4tPfecf+CpMZ8P92t+PdM2ULsY3REGRYLF3NbkRitOjzu4fTCbHkBUYduh42s2tsdsJ09mBnACWnaZw+lhJlAMietw5wc7mMovQM0U2s9vnP0KMHe0URDw/FUKs/kwI5M4sAYzKEOJ0KabruQv1bJMFMsF+2MrUbFr2Sw/L7gUt/WZxOLaTqiBTtWsgPGeOZKbu7i7xkyYoONCjrNLEHPsgRWV4A9gP8jjdx74DmngzHwyaiA==YOl4-----END PGP SIGNATURE-----

L

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

(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 49659@debbugs.gnu.org)

87fsw8k8sw.fsf_-_@gnu.org

Maxime Devos <maximedevos@telenet.be> skribis:

[...]

Yes, makes sense.

Alright.

I’d still err on the side of making the change only for target-x86-32?,because that’s the only case where we know it’s needed.

I’d still err on the side of making the change only for target-x86-32?,because that’s the only case where we know it’s needed.

OK.

Makes sense. Seems to me that this should simply be implementeddifferently to avoid the inconsistency in the first place (or one couldignore IA32 altogether…).

I’m no expert but that makes sense to me.

Could you send an updated patch?

If you think of a way to fix the issue in Guile itself, we can also dothat. :-)

Thanks for the investigation & explanation!

Ludo’.

Could you send an updated patch?

If you think of a way to fix the issue in Guile itself, we can also dothat. :-)

Thanks for the investigation & explanation!

Ludo’.

M

[PATCH v2\ core-updates v2] gnu: guile: Fix failing tests on i686-linux.

(address . 49659@debbugs.gnu.org)

20210720213417.5285-1-maximedevos@telenet.be

i586-gnu might have the same issue.

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

Fixes: https://issues.guix.gnu.org/49368.--- gnu/packages/guile.scm | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)

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

Fixes: https://issues.guix.gnu.org/49368.--- gnu/packages/guile.scm | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)

L

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

(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 49659-done@debbugs.gnu.org)

87v953hj50.fsf_-_@gnu.org

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

Maxime Devos <maximedevos@telenet.be> skribis:

I tweaked the commit log and pushed asfccc0275091af10a46471c68df525d19f446af9e.

Looks like we should be able to move forward with this branch now,thank you!

Ludo’.

Looks like we should be able to move forward with this branch now,thank you!

Ludo’.

Closed

M

(address . 49659@debbugs.gnu.org)

875yx3pvpq.fsf@gnu.org

Hey,

Thanks for taking care of that Maxime & Ludo :). Should we create acore-updates-frozen branch that Cuirass would build for the "all"subset? I can take care of that if so.

Mathieu

Mathieu

L

(name . Mathieu Othacehe)(address . othacehe@gnu.org)

8735s5cs9q.fsf@gnu.org

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Mathieu Othacehe <othacehe@gnu.org> skribis:

There are “two last things” to check IMO:

1. Make sure powerpc64le-linux is in a good state. Can we get it built? (We discussed adding a worker on the OSUOSL machine but I think we eventually dropped the ball.)

2. https://issues.guix.gnu.org/49597 will trigger rebuilds. I was waiting before applying it so we get several people looking into it; Maxime had valid criticism, I’m interested in hearing from others too. :-)

Once we’re OK on these two fronts, let’s branch ‘core-updates-frozen’and unleash our package-fixing superpowers!

Ludo’.

1. Make sure powerpc64le-linux is in a good state. Can we get it built? (We discussed adding a worker on the OSUOSL machine but I think we eventually dropped the ball.)

2. https://issues.guix.gnu.org/49597 will trigger rebuilds. I was waiting before applying it so we get several people looking into it; Maxime had valid criticism, I’m interested in hearing from others too. :-)

Once we’re OK on these two fronts, let’s branch ‘core-updates-frozen’and unleash our package-fixing superpowers!

Ludo’.

M

(address . 49659@debbugs.gnu.org)

bafd3cf0cd2053d2acf37d402abb226d63ee4a8b.camel@telenet.be

Ludovic Courtès schreef op vr 23-07-2021 om 11:07 [+0200]:

For --target=x86_64-w64-mingw32, the patchhttps://issues.guix.gnu.org/49694 is required,to fix a build failure of x86_64-w64-mingw32-binutils.

Greetings,Maxime.

Greetings,Maxime.

T

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

5701551.jmBiHemN7o@popigai

Hello,

Em sexta-feira, 23 de julho de 2021, às 06:07:45 -03, Ludovic Courtès escreveu:

Em sexta-feira, 23 de julho de 2021, às 06:07:45 -03, Ludovic Courtès escreveu:

Perhaps libdrm and Mesa could be updated before the freeze as suggested by John Kehayias¹?

Or could/should that be done on a branch apart from core-updates? Not sure if that’s what Ricardo’s suggestion about creating a new branch means.

-- Thanks,Thiago

¹ https://lists.gnu.org/archive/html/guix-devel/2021-07/msg00105.html

Or could/should that be done on a branch apart from core-updates? Not sure if that’s what Ricardo’s suggestion about creating a new branch means.

-- Thanks,Thiago

¹ https://lists.gnu.org/archive/html/guix-devel/2021-07/msg00105.html

?