[powerpc64le-linux] "check" package fails to build

  • Done
  • quality assurance status badge
Details
2 participants
  • Chris Marusich
  • Efraim Flashner
Owner
unassigned
Submitted by
Chris Marusich
Severity
normal
C
C
Chris Marusich wrote on 11 Apr 2021 03:00
(address . bug-guix@gnu.org)
87v98ty6rr.fsf@gmail.com
Hi,

On commit 83f8b6d32c76c56e4bb58eeb5af1259028d7ee72, on
powerpc64le-linux, the "check" package fails to build. This prevents
many other packages from being built successfully. It succeeds when
built on x86_64-linux, so the problem is probably specific to
powerpc64le-linux.

The following tests failed - I have attached test-suite.log:

FAIL: check_check_export
FAIL: check_check

I've attached test-suite.log. There's a lot of messages. However, the
following ones caught my eye:

Toggle quote (2 lines)
> check.c:584: Bad status in set_fork_status

I tried adding some debug statements here, and it seems like the value
is -1 for some reason. I don't know if that's really a problem,
though. I suspect maybe it's just irrelevant noise... Not sure.

Toggle quote (2 lines)
> 19%: Checks: 260, Failures: 165, Errors: 45

Lots of failures, lots of errors. Consider these:

Toggle quote (3 lines)
> check_check_sub.c:74:P:Simple Tests:test_fail_if_pass:0: Passed
> check_check_sub.c:83:F:Simple Tests:test_fail_if_fail:0: This test should fail

The code is:

Toggle snippet (19 lines)
START_TEST(test_fail_if_pass)
{
record_test_name(tcase_name());

fail_if(1 == 2, "This test should pass");
fail_if(0, "This test should pass");
}
END_TEST

START_TEST(test_fail_if_fail)
{
record_test_name(tcase_name());

record_failure_line_num(__LINE__);
fail_if(1 == 1, "This test should fail");
}
END_TEST

The fail_if macro is defined thusly:

Toggle snippet (16 lines)
/*
* Fail the test case if expr is false
*
* This call is deprecated.
*
* NOTE: The space before the comma sign before ## is essential to be compatible
* with gcc 2.95.3 and earlier.
* FIXME: these macros may conflict with C89 if expr is
* FIXME: strcmp (str1, str2) due to excessive string length.
*/
#define fail_if(expr, ...)\
(expr) ? \
_ck_assert_failed(__FILE__, __LINE__, "Failure '"#expr"' occurred" , ## __VA_ARGS__, NULL) \
: _mark_point(__FILE__, __LINE__)

This is pretty confusing to me. The comment says "Fail the test case if
expr is false", but it sure looks to me like it fails the test case when
expr evaluates to true. Am I confused? I feel confused. :-)

Anyway, regardless of how both of those test cases are supposed to run,
it seems likely that something funky is going on in the 1 == 1
evaluation.

Here's another example:

Toggle quote (3 lines)
> check_check_sub.c:219:F:Simple Tests:test_ck_assert:0: Assertion 'x ==
> y' failed

The test is:

Toggle snippet (20 lines)
/* These ck_assert tests are all designed to fail on the last
assertion. */

START_TEST(test_ck_assert)
{
int x = 3;
int y = 3;

record_test_name(tcase_name());

ck_assert(1);
ck_assert(x == y);
y++;
ck_assert(x != y);
record_failure_line_num(__LINE__);
ck_assert(x == y);
}
END_TEST

There are some double-related test failures, too:

Toggle quote (3 lines)
> check_check_sub.c:1458:F:Simple Tests:test_ck_assert_double_finite:0:
> Assertion 'x is finite' failed: x == inf

The corresponding test code:

Toggle snippet (16 lines)
START_TEST(test_ck_assert_double_finite)
{
double x = 0.0001;
double t = 1;

record_test_name(tcase_name());

ck_assert_double_finite(x);
/* MS VS doesn't allow explicit division by zero */
x = 1.0 / (1.0 - t);
record_failure_line_num(__LINE__);
ck_assert_double_finite(x);
}
END_TEST

Some timeout-related tests fail, too:

Toggle quote (3 lines)
> check_check_sub.c:2650:E:Timeout Double Scaling
> Tests:test_sleep9_fail:0: (after this point) Test timeout expired

A particularly suspicious failure involving "long double":

Toggle quote (4 lines)
> check_check_sub.c:1830:F:Simple
> Tests:test_ck_assert_ldouble_eq_tol_with_mod:0: Assertion 'fabsl(2%f -
> 3%d) < 2%p' failed: 3%d == 1, 2%f == 0, 2%p == 0

The code:

Toggle snippet (14 lines)
START_TEST(test_ck_assert_ldouble_eq_tol_with_mod)
{
int d = 2;
int f = 2;
int p = 2;
record_test_name(tcase_name());
record_failure_line_num(__LINE__);
ck_assert_ldouble_eq_tol(3%d, 2%f, 2%p);
}
END_TEST

The ck_assert_ldouble_eq_tol macro is:

Toggle snippet (17 lines)
/**
* Check two double precision floating point numbers to determine if X≈Y
* with specified tolerance
*
* If not X ≈ Y with error < T, the test fails.
*
* @param X floating point number (long double)
* @param Y floating point number (long double) to compare against X
* @param T tolerance (long double)
*
* @note If the check fails, the remaining of the test is aborted
*
* @since 0.11.0
*/
#define ck_assert_ldouble_eq_tol(X, Y, T) _ck_assert_floating_absdiff_op_tol(X, Y, <, T, long double, "L")

I know that there are "long double" problems on POWER9 in some cases...
I wonder if this is the root cause of the issue here? Perhaps we need
to pass a flag or something? Could it be that we need to compile gcc
with the --with-long-double configuration option after all, to fix this?
As described here, we don't currently do that:


I don't really know what's going on, but I'll try compiling GCC 7.5.0
with the --with-long-double option, and I'll report whether it fixes
this issue. If someone has any other idea before then, I'm all ears.

--
Chris
Attachment: test-suite.log
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmBySjgVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadFwsQAMJHoPD98q34dVBoaeGHTm8oCqWV
X+pZDbFVSVdTbUJqMQxnCclsE49C5PBGzvdH1ffEn5rDvjouXmadfp4pyZoQS0wO
TkdxDVzKEXecjA3bgM1zkFX/WInq/qDrEjdTiZmQ/RJZwdxHNc59keVe1M4Sv4sM
GbWSrdazBuzuRe5XFFmu2vr5AmYfladxJT+/5Xbv+TNkw2faWngpNqDnB1h/tdcf
PX21bEwagoFd0H7Fzbrt833dwj/987U5pH2J3SSqWsK+mh4IqqADB7h3wZbA/hq1
+GIJ+1ZW8SVSWB+c6ie764uG86+Mko+DAwB9hUbzHY8DMj6V1N9k0lS/V4aJCi8P
00Npw3bAoIWk6v/TVn9uamtD+2Fth3WHBPdJBtbW8SnxN+8UgzxAliQZ483oShBs
4SNarIOkqXBa1CMm1YtRtkbMxwfhQUj2B8w2hxY5O5AUc8KHOWE4JUXwFUHFfqhi
4UK/id3cQiwyBfJ7oqQ2hsQRT4qZxJfOVs/5baNcL/T9usiLV1LN0/HhPD7jvL1g
wCQmr8D+3dLwF5UBqHpQD2TzhHSvpvkbIf78cUNCiN+LM2hSdfaI7Q8zWbVLmdKj
HrECramFlB86qHx6o5uwTi8bzo+4mgs/BbJLZSQHbyVzzzknSQhL56HHfm+har3O
GKwSgR38Tf3GcKV4
=dxUF
-----END PGP SIGNATURE-----

C
C
Chris Marusich wrote on 12 Apr 2021 21:10
(address . 47698@debbugs.gnu.org)
87a6q32ub8.fsf@gmail.com
Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (4 lines)
> I don't really know what's going on, but I'll try compiling GCC 7.5.0
> with the --with-long-double option, and I'll report whether it fixes
> this issue. If someone has any other idea before then, I'm all ears.

It did not seem to fix the issue. I tried using a patch like the
attached, but the "check" package still seems to fail its test suite in
the same way as before.

Something else must be going on. Maybe the best thing to do is to try
to manually create a minimal reproducible case, and then investigate
using that simpler case.

--
Chris
From ad89f9f59d22cc10fbf7dd6f738ce15a6e79b640 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Sat, 10 Apr 2021 18:16:17 -0700
Subject: [PATCH] gnu: Simplify the use of --with-long-double-128 on
powerpc64le.

In short, this change adds the "--with-long-double-128" configure option in
one place and removes it from two other (now-redundant) places. It does not
cause any rebuilds on systems other than powerpc64le-linux.

* gnu/packages/gcc.scm (gcc-configure-flags-for-triplet): Add a clause for
targets starting with "powerpc64le-" which adds the "--with-long-double-128"
option. This causes any package using this procedure to be built using this
new option on powerpc64le systems. In particular, this affects the gcc
package and the gcc-final package, in addition to all the other versions of
GCC defined in (gnu packages gcc).
* gnu/packages/commencement.scm (gcc-boot0)[#:configure-flags]: Remove the
code that adds the "--with-long-double-128" configure option for powerpc64le,
since it is now redundant. The gcc-boot0 package uses (and adds to) the gcc
package's configure options. This means that the above change in gcc.scm is
sufficient to ensure that the gcc-boot0 package's configure options will
include "--with-long-double-128" on powerpc64le systems.
* gnu/packages/cross-base.scm (cross-gcc-arguments)[#:configure-flags]: Remove
the code that adds the "--with-long-double-128" configure option for
powerpc64le, since it is now redundant. The cross-gcc-arguments procedure
uses (and adds to) the configure options of its xgcc argument (a package).
This means that regardless of which gcc from gcc.scm is used as the xgcc, the
above change in gcc.scm is sufficient to ensure that the cross-gcc-arguments
procedure's configure options will include "--with-long-double-128" on
powerpc64le systems.
---
gnu/packages/commencement.scm | 7 -------
gnu/packages/cross-base.scm | 6 ------
gnu/packages/gcc.scm | 3 +++
3 files changed, 3 insertions(+), 13 deletions(-)

Toggle diff (51 lines)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index d4511ed914..db564db9c4 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2819,13 +2819,6 @@ exec " gcc "/bin/" program
"--disable-shared"
"--enable-languages=c,c++"
- ;; boot-triplet inserts "guix" in the triplet.
- ,@(if (equal? "powerpc64le-guix-linux-gnu" (boot-triplet))
- ;; On POWER9 (little endian) glibc needs the
- ;; 128-bit long double type.
- '("--with-long-double-128")
- '())
-
;; libstdc++ cannot be built at this stage
;; ("Link tests are not allowed after
;; GCC_NO_EXECUTABLES.").
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 180594509b..c1e5f2eb79 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -153,12 +153,6 @@ base compiler and using LIBC (which may be either a libc package or #f.)"
"--disable-decimal-float" ;would need libc
"--disable-libcilkrts"
- ,@(if (string-prefix? "powerpc64le-" target)
- ;; On POWER9 (little endian) glibc needs
- ;; the 128-bit long double type.
- '("--with-long-double-128")
- '())
-
;; When target is any OS other than 'none' these
;; libraries will fail if there is no libc
;; present. See
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a412c93c29..22a0f35422 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -79,6 +79,9 @@ where the OS part is overloaded to denote a specific ABI---into GCC
;; Cilk has been removed from GCC 8 anyway.
'("--disable-libcilkrts"))
+ ((string-prefix? "powerpc64le-" target)
+ '("--with-long-double-128"))
+
(else
;; TODO: Add `arm.*-gnueabi', etc.
'())))
--
2.30.2
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmB0mwsVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadtjIP/j2zQAOgY2xW21xyn7ULX2hYJ3eC
MetRZPULhDm+GlYzYy1KW2Ui6JAW3sZfQqisS7ud72WzDJYdvwXx2JMf+JwY/hjI
IOOztXpl0LeWAZmAnGvEecBLyxlMQcSlSeY2NOtuRoegA7fzMTJfqpIXTdiTL+lE
SZnZU1BKqFk/Y3yV+fWAbyeEgeQ2QIbOgQJK3FjQc9ML0oH4HbrsNcmusl0rIJ5s
jO8H9o5Igs6XRB7KdThi3XLBqJ8L0P/GnLZSKFNfR19BlYBu79ZBGPP7cZrcvk9h
JBhNHYVvm3E6zzR5NDfpOFbtkV+laqUZHZQ7KzO7561lGo5pfNO1OPsPNuhD1hoH
qE/xWZT6l0elAjAoV5AXBvo7YLYlXj+4apMZtVtD0W7UA1S28UKvXuvT605X+3v2
yBphaqhqFuMfhbaWr5qBtH/TmiicfjB+zVWSl8hjyUVEbE2hPbW8vrlt28qoiwBz
DpZesUw5OMY5Oe66loFcT2UYRKHkFe64cm5S11WhjihKB49SpHbhLFmbziZ/IUiH
KXX537/k+X0YQsLZCZbUu7KO9h2wvGIVtePdxMGau/hd/aJUEejtZTI7wr/plIy1
iR4cjcUHPQQlLFqKk0NTaqGJjY7lmNgu+o4nxGZzCidiDp2YaCz4l5zerOtZ9l5X
bbJG5QPdv8ImbFk8
=dMQC
-----END PGP SIGNATURE-----

E
E
Efraim Flashner wrote on 13 Apr 2021 13:12
(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 47698@debbugs.gnu.org)
YHV8k4KvUyqDiI4z@3900XT
We should probably apply this patch anyway to core-updates. Even if it
is implied for powerpc64le it'd be better to make it true always and
have it join the other gcc architecture-specific configure flags.

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmB1fJMACgkQQarn3Mo9
g1EtaBAAlE6IGeELBuLcZoTehiH20Olw1vFb501bS5eT3Yltoeq9e3Nl1B0amEh0
ScOW8Mw6yZlr/RghVryRXkcputZ4otT0L6aq5W1QIsFxs0GZS0wIng5SpwY5Zzqj
DHGfs2AivrSO6vGe+dtLVy1NIEmNgXJeIvgpcDeaAgENLD3MYOkaygrwZoKMgAnX
4/X3msJFYeAawVjQqjOosFa6aLX5uXV++A+vmLoUB/DtA98Nd2H3trP24LtACrEe
jQ1wGOdmgdKqnFojC9x9D7kdiIeNaL0Cqhh71AWgd0YJPw43C6wHQsAtzYdFksog
yNGcrJJjJ0gM1rALqljWPucJfbRh1LHobeoj5/pJIVYUDSRGeUMb9X/v0ootX1wl
KsXvGUtBohPrzLvnz7Yk2yIP+y1xZkZ9w+Z8+dd6Q4sHwVhn8MVYJo98YT3f90AK
SlSrHxchbiJWAXTHbTKx+Cdyc1ISlON+uL5rQM2G8asbBJLmBVEKFdPjq+kaBtiX
h6GtBiMLo7m4UpYGL3bg+HrsUn7FiV0y47GbdUlGj+Zjf+1nyePZmcHhrIx2X6UZ
Sb3h9fA7ck3bME30MrRCJRe/AxN/20COl/nGQWuPIHcGh/GjB/kQt/hq98jfD9lq
xjGyyjgjwXIfsTRrmodmm+Lk841Ns3LnXlLx6xmIEkCRpM6kaAM=
=wUDm
-----END PGP SIGNATURE-----


C
C
Chris Marusich wrote on 14 May 2021 09:45
(address . 47698@debbugs.gnu.org)
87wns1daic.fsf@gmail.com
Hi,

I tried to make a minimal reproduction case, but I couldn't figure it
out after a few hours of messing around with it. So, I've reported this

Hopefully they can help provide some guidance.

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

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmCeKosVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadI4MP/RyvZq7K6+bTpEBm3NH3qryXGcaA
RQf0kpLjcz8PZVWzX4A/RCVM1WwDbctoNodj9+2Rk1HzGXQrXvg392o0nJlMMMOE
YnZNZtYdO+HrA1KuzaVn6s/ClUkTOykk3+XQ6nFIAclbtDyYcjYHj+b/Zly21KUK
2hO4cadt34pwnP6v+f3BYlULG8qiPJduuSF8FvOpX2RFnCNE6RjhqO19++77VRXW
JWd4KWboe5JZjqvI3iBYNoYR3pshJoTOxptx+aUjEEhIrksY2ULWGMN5I3aDXpdR
/BvwpBY3Af2khxKC72JPp5tf8pOxMnYaKF/GGFwt6hO0FsOpPwOKFuYTUxguxPO4
Knyfpf443hE6cLmWcPtgGafIDuflZK6WczSt6pMjJzRYcNFRdBWixF/TNxDad4WJ
cyFqX5vF+zEN2VhuwL2KnQvVhqmxSDc4UdBCZhWxWMmsqtv1GKT6J9RTC+3jEL+h
+RMMDKP24GNzRVDHEgLyJp0S1BhvPRc7NrXZXl7xnWIlAmLN/oFbLMVKg4yJ//nV
AMVlKhnlv9h19vtIAEcJ+li3UwieywQkRCeeIeBC26CoZPisgJg/GantjROlLKsy
4OFkMf0qrnID1N0Bkw6CK/9J1ScsXjnx+h4ut+lffN3hBDEKZ28tk8a0ZlQ4dlaM
PgW90dwtGqoZ5mqr
=j1YE
-----END PGP SIGNATURE-----

C
C
Chris Marusich wrote on 4 Jun 2021 08:58
(address . 47698@debbugs.gnu.org)(name . Efraim Flashner)(address . efraim@flashner.co.il)
87eedit8tu.fsf@gmail.com
Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (3 lines)
> [...] I've reported this issue upstream:
> https://github.com/libcheck/check/issues/333

Branden Archer replied in the above issue. In short, the unreleased
upstream commit 4fbe702fa4f35bee8a90512f9f59d1441c4ae82e fixes this
issue on PPC platforms. Here's what the commit does:


Adjust test suite for 106-bit long double precision

On PowerPC architectures (ppc, ppc64el, powerp) 'long double' has a
precision of 106-bit, compared to 80-bit precision on amd64.

This leads to the test_ck_assert_(float|double|ldouble)_eq_tol succeed
rather than fail as expected, cause 0.003-0.002 will be actually
slightly bigger than 0.001 and not slightly smaller.

Increase the change to the tolerance, so it will be on all architectures
smaller than the difference of ~0.001 and the unit tests will fail as
expected.

This commit was merged to the check repository's master branch after its
latest release (0.15.2). It will be included in the next check release,
but until then, we will have to apply the fix as a patch to our check
package. I've attached a patch that does this.

--
Chris
From 7692295f970a292a3f3db31fc21d05efd97dcb25 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Thu, 3 Jun 2021 23:12:24 -0700
Subject: [PATCH] gnu: check: Fix failing tests on powerpc64le-linux.

* gnu/packages/check.scm (check)[source]: Apply unreleased upstream commit
4fbe702 as a patch.
---
gnu/packages/check.scm | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)

Toggle diff (35 lines)
diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm
index 6641a0de58..069d4e05fc 100644
--- a/gnu/packages/check.scm
+++ b/gnu/packages/check.scm
@@ -146,7 +146,27 @@ like Jasmine or Mocha.")
version "/check-" version ".tar.gz"))
(sha256
(base32
- "02m25y9m46pb6n46s51av62kpd936lkfv3b13kfpckgvmh5lxpm8"))))
+ "02m25y9m46pb6n46s51av62kpd936lkfv3b13kfpckgvmh5lxpm8"))
+ (patches
+ (list
+ ;; This patch fixes some tests that would otherwise fail on
+ ;; powerpc64le-linux. Without this patch, the tests make certain
+ ;; assumptions about floating point number precision that are not true
+ ;; on that platform.
+ ;;
+ ;; TODO: Remove this patch when updating to the next check release,
+ ;; since it will be included there. See:
+ ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47698
+ (origin
+ (method url-fetch)
+ (uri
+ (string-append "https://github.com/libcheck/check/commit/"
+ "4fbe702fa4f35bee8a90512f9f59d1441c4ae82e.patch"))
+ (file-name (string-append name
+ "-fix-test-precision-for-ppc.patch"))
+ (sha256
+ (base32
+ "04qg1p9afdd6453k18qskazrvscysdcjz9j6w4i6p5x4xyma19v6")))))))
(build-system gnu-build-system)
(home-page "https://libcheck.github.io/check/")
(synopsis "Unit test framework for C")
--
2.30.2
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmC5zw0VHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadc68QANQLIommJvgPGkSki6rT2JVcuxQd
qXPZDRxcGS2kOVu321wHGuScMZJ9rUjtmTjA7dqN56CfqqEe+AM+E1NP2GKcAqsD
macemd285NyoRIFuMcJwBguMMDd06RsQJIxtNzmE4fzxbbrcJ/F6QD2DZKXbRzvw
6cbKyoj7sk3iGUMz8agsD9Wlspi+PzNwp0OihZY48QPc9l/hppUHzYl79+1Gr8ER
5CRX8YfAy02Wn/px/u0FQKab0QCTw56AetsThvS8PMkhJJpZN35ejtS5HVFvLYBN
VoY4ILJR6GHdyk4jzeiVgx9wWoNXbieFBV0bQhc+/8HaL53t7Lhzi5iOrSFY69cK
C9NCIiSfO8K7WrS4bkm9yrdJnxPdPrF/QxDXqJuI0FmJH2FYYcSEAtIL7hOEyp9S
ph/3I0EmbaGsrgtnhhT9nSHmqPo4fUKTnfhpw3UJJ8w1fpOfADDl3ZfVzD+fmhha
YIMWpZ+aFVcbQbhsEDhLLkPKF5TB+CcogFUiF3r6nF4U0roOioMgaoNyTDOq3CIG
33LIL/T9+qtIvXY/tbhfnP80dHPlIvL9pIYvd4r6iTAiKSNGDV0Yqc8wMcWqx17X
ZXNSqz6uqQPOvI2ZjoRCv9QRH9AkgR6YaLzRXG1B1inKXHDMNy/hHUtoDvBnwlyX
0hsxKndWeu3H2bXP
=+RVt
-----END PGP SIGNATURE-----

E
E
Efraim Flashner wrote on 4 Jun 2021 11:11
(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 47698@debbugs.gnu.org)
YLnuTxJuDXM37KEs@3900XT
On Thu, Jun 03, 2021 at 11:58:21PM -0700, Chris Marusich wrote:
Toggle quote (32 lines)
> Chris Marusich <cmmarusich@gmail.com> writes:
>
> > [...] I've reported this issue upstream:
> > https://github.com/libcheck/check/issues/333
>
> Branden Archer replied in the above issue. In short, the unreleased
> upstream commit 4fbe702fa4f35bee8a90512f9f59d1441c4ae82e fixes this
> issue on PPC platforms. Here's what the commit does:
>
> https://github.com/libcheck/check/commit/4fbe702fa4f35bee8a90512f9f59d1441c4ae82e.patch
>
> Adjust test suite for 106-bit long double precision
>
> On PowerPC architectures (ppc, ppc64el, powerp) 'long double' has a
> precision of 106-bit, compared to 80-bit precision on amd64.
>
> This leads to the test_ck_assert_(float|double|ldouble)_eq_tol succeed
> rather than fail as expected, cause 0.003-0.002 will be actually
> slightly bigger than 0.001 and not slightly smaller.
>
> Increase the change to the tolerance, so it will be on all architectures
> smaller than the difference of ~0.001 and the unit tests will fail as
> expected.
>
> This commit was merged to the check repository's master branch after its
> latest release (0.15.2). It will be included in the next check release,
> but until then, we will have to apply the fix as a patch to our check
> package. I've attached a patch that does this.
>
> --
> Chris

I'm trying it out now on powerpc-linux, where check was also failing.


--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmC57kwACgkQQarn3Mo9
g1E8YhAAoL+/umSXmWpGW9vC88Mj3qdGlcQe/a7hfUM10HuVr3uNH0KlM0cuhIzM
lca77/nXTxSk0fzlXLWpUzZudm1KVI4eC6SiLx89v/bljNloK/kJbJCsmHBekuMz
CUwBZ4yUZGQQEs2uhNtvk7Ty4ekkv5d7UocrQMQkKdRYf9ZV7AJabYazQcKX8+K8
r0NJ3eqOkT+q0deC/fcuLQR6/golEae1M84Ct0WqzHJrIgkQAVmf6kjgaenLbHQ2
u/zSY9vcRwkgvQclJaSRnyNBtqAoHY6Ua4cnmGN3NR6BBcGPW5BLho0bs71gJ+l7
gUIPfIKm7W5QqlhScJFEduXLwfs7qgxY02vxpkIcyBP0hcUqqfi1XU0a2sWecCF4
C/bRXmiy9ZEnWtaQPE0NeY/YKdYi29fOnyj8BPRVPDdtaMRcrNyWj6mSwQh93AKW
FOXuyr7M1iE0GyLNIZ0dQys9qQFNeWuSpSrd6j4R2Rg7eKUNJ7tUv6znM6wJReUT
T5JPeKOaZXv9IXXnkG5RCiAqu0Dg5bPqp7ep7aC87rzIVaU6/vhU3tVqtLXUHN7L
2F4TEWSdsee0v/JfYD2QOdeEIhzIqmg6i3Z5JzgkvDkPRfoBDaU3EoZn0n9K+w0Y
jypZirgcmIV0jZz/ndimz3w73aHEkqIrIUcfGBKq+2kFnZaKauE=
=x8Ud
-----END PGP SIGNATURE-----


E
E
Efraim Flashner wrote on 4 Jun 2021 11:36
(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 47698@debbugs.gnu.org)
YLn0FUb+7W4egMTb@3900XT
On Thu, Jun 03, 2021 at 11:58:21PM -0700, Chris Marusich wrote:
Toggle quote (32 lines)
> Chris Marusich <cmmarusich@gmail.com> writes:
>
> > [...] I've reported this issue upstream:
> > https://github.com/libcheck/check/issues/333
>
> Branden Archer replied in the above issue. In short, the unreleased
> upstream commit 4fbe702fa4f35bee8a90512f9f59d1441c4ae82e fixes this
> issue on PPC platforms. Here's what the commit does:
>
> https://github.com/libcheck/check/commit/4fbe702fa4f35bee8a90512f9f59d1441c4ae82e.patch
>
> Adjust test suite for 106-bit long double precision
>
> On PowerPC architectures (ppc, ppc64el, powerp) 'long double' has a
> precision of 106-bit, compared to 80-bit precision on amd64.
>
> This leads to the test_ck_assert_(float|double|ldouble)_eq_tol succeed
> rather than fail as expected, cause 0.003-0.002 will be actually
> slightly bigger than 0.001 and not slightly smaller.
>
> Increase the change to the tolerance, so it will be on all architectures
> smaller than the difference of ~0.001 and the unit tests will fail as
> expected.
>
> This commit was merged to the check repository's master branch after its
> latest release (0.15.2). It will be included in the next check release,
> but until then, we will have to apply the fix as a patch to our check
> package. I've attached a patch that does this.
>
> --
> Chris

With this patch check builds for me on powerpc-linux

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmC59BIACgkQQarn3Mo9
g1GwIQ/+JcrvgZHbCC1VspzcRWsLDJX8vsRPQKtWiKVncuxbmEVJ9tmkhdfA8ckJ
DXpqURJy/YhNgIrNtfBVgr5W2KS6FTm46HrKWyvgbyi+Zkbe6Rch+oClQiM6GrWc
vniPRHZ9o1nxfNXffuXMa4FB5t04aTtnqPcvNSTTbj5R4NiAgpbRZsZUR/ipbVKm
IdqUqL9pxT7UfJTKNu+QBTG9pH0Krhx+kW49RrfqxYZAAKf77WZ15lPnCU15DiaR
QHRF2CFnkWcWTnjjctLDiNI22FeVlMhPmcokjS+JCk2ijZohl99rIG5k6e1CvAju
ma3aLBJ0reolJVv+DkMX3TGf0TM6KlPH9T4124lE5ZXww9Yeykqv8ROKiEF8Qryc
JzojXBYLEtDzvPXGb+RJ2OIlupDCVHLC8wc4wJvuvNEoWO06hZInoEfz9YGXUOul
c44ATRICiYiqXJU4xG2FuVEWlmVvFmd//XSeaPKSGRiWtgSl1rQw9OlCmWg05T+t
xXxK4NH15D4UNuDPzJJF6D/S5gfo+pGrfgF8aG/zvKkNbyceMB9nRvPw4WWhc3eQ
J+Js0MlZxxoTF4/gmHeWW8rWPLLN0A9rPvLoOmZd99+FjSr5tILwHTOsMbNZfmmt
Dk/jsQXbCGw/xiIo3752fI7ql9pwdDB5ommtZHmxP9+0CeuglNY=
=pdRk
-----END PGP SIGNATURE-----


E
E
Efraim Flashner wrote on 8 Jun 2021 10:22
YL8oyy5tbslLRvAI@3900XT
LGTM!


--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmC/KMgACgkQQarn3Mo9
g1FZNxAAofn9Iq0DcHmH/+f0dv8mH9X1pKckcOC7hmSsK4x4alEkZBMEmHtd+iAF
W9BHkptSvqOPrqK6ibpYwH8IMMf3KURs1d27TbPzdV7xBfSFspERZtrYR4d4dWeK
mCIwjO51T2uLhX8QdQAACBJZRdbAT/ZpJcRGqmNSN7k+MuB9je4DLIxxYEJOv5Xo
07nrpp+Q+8E3gndszzfo73JCiuLBPPS8pi+RChgm3tIG1NMMt+pSP+zd5LB8hmOX
7V2+CvDKWmQndW/IiSuW1MBZT9DAjNnYJTEqXuDI0dKMwLNLJm2ytpAuTnBdpeCE
v74EuCDWe6DELp5exwe7K6DTwer+HONjJub04szOJj5+Is+EeR06LwyMduHLwwmU
iRXj8RlngKCqFRnw3buQ1THxW2GjSSEorupI3u+LxC7LMNQj8+Hugi7HxXLtYOqz
YX1ccj3rWtJNkI9uDbm/Ppb3X0Mu67zlJbOR28k5IXu411stuXZk9siE5M23mDb8
KI5pITPWzFAcOuHhXPMhSGgz/pfhdgjYn5q+Q301B8FoU/6QCQIIAmjBvp0jr5kr
mcmkjtS11YYjCgLf1i7vS3wsjWQxZ1eXqaqMqpdu2NxX0Gwz0m7t2dP/fJ+elNyd
Bw0K02N33ArK7bS6JJPGkejve0QvNb+mCKxAHqxftR8n34DPNDA=
=jOp+
-----END PGP SIGNATURE-----


C
C
Chris Marusich wrote on 18 Jun 2021 20:09
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 47698-close@debbugs.gnu.org)
87o8c36o4z.fsf@gmail.com
Committed to core-updates in bcdc13454c4afab37b650d4bbfa95e539060619f.

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

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmDM4UwVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadLKgQANNGyIs8U8O5SCE5XmBKS25nMUXP
ZiGjmLoFRM6BBrAzgMZapd2TaxfaltEpTcH8Ur+KmUomqYIRK/lv4PX7Zrp0wkoq
+P7Jhfkd11ptdpxO6lWMrvXT/Rw6P7xBk6czUCcPjfxCMsDgHI2OQSyT3cUbTbGh
y6FbKDwblMut5+93/kBL6rPHFP3GnyHNnDOSPKTG2qbe5+hK+aI7TBtQMf8A4lxs
XB/I+bRTimrv1dxdmY1ybYYjbXg605nv7/XVm68ek/3VQAa/pQzPAfV+AB/jUgqc
/w99Ldkg9xFjbEsINJ1I8BT40otf7j/9NWGr2KgJN3yLMfAUBdSEcfZ3/fh9nqo9
a+GvExjPKVnvYBM1oiFS+WIo2IkXXF/Uj7Rq/BU4BDk9iXjIhKNWNG2ZrVWQCrtA
1NkvG0vseKwVZBch6fRp0V6nBpYm+0xiIOtaTwWU+eDCfs0C1nxG1qvJ8Jrc5Lds
v1cj/OI8d7NQJoO05bACqJHMztb2NJBs0BsjEdFLwIh78XNoT90XNU8J8fZdPmGZ
VVJgJgPsgEu8YddPlGj6PvA7uBK1x4v3kFYtlVuOpFTuc9yhIWHbnJDMGqMurcVo
+6jBimfA7P4FIemwInqoPpyyHHiHLhi+PkCcamONOp3nE6qyUXG/RSD/UTR8OPlX
beZmOuRU2NrFDeQg
=0/qM
-----END PGP SIGNATURE-----

?