GNU bug report logs -
#47698
[powerpc64le-linux] "check" package fails to build
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47698 in the body.
You can then email your comments to 47698 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Sun, 11 Apr 2021 01:01:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Chris Marusich <cmmarusich <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Sun, 11 Apr 2021 01:01:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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:
> 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.
> 19%: Checks: 260, Failures: 165, Errors: 45
Lots of failures, lots of errors. Consider these:
> 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:
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
The fail_if macro is defined thusly:
--8<---------------cut here---------------start------------->8---
/*
* 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__)
--8<---------------cut here---------------end--------------->8---
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:
> check_check_sub.c:219:F:Simple Tests:test_ck_assert:0: Assertion 'x ==
> y' failed
The test is:
--8<---------------cut here---------------start------------->8---
/* 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
--8<---------------cut here---------------end--------------->8---
There are some double-related test failures, too:
> 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:
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
Some timeout-related tests fail, too:
> 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":
> 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:
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
The ck_assert_ldouble_eq_tol macro is:
--8<---------------cut here---------------start------------->8---
/**
* 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")
--8<---------------cut here---------------end--------------->8---
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:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47349#11
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
[test-suite.log (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Mon, 12 Apr 2021 19:11:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 47698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Chris Marusich <cmmarusich <at> gmail.com> writes:
> 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
[0001-gnu-Simplify-the-use-of-with-long-double-128-on-powe.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Tue, 13 Apr 2021 11:40:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 47698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Fri, 14 May 2021 07:46:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 47698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
issue upstream: https://github.com/libcheck/check/issues/333
Hopefully they can help provide some guidance.
--
Chris
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Fri, 04 Jun 2021 06:59:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 47698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Chris Marusich <cmmarusich <at> 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
[0001-gnu-check-Fix-failing-tests-on-powerpc64le-linux.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Fri, 04 Jun 2021 09:13:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 47698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Jun 03, 2021 at 11:58:21PM -0700, Chris Marusich wrote:
> Chris Marusich <cmmarusich <at> 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 <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Fri, 04 Jun 2021 09:38:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 47698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Jun 03, 2021 at 11:58:21PM -0700, Chris Marusich wrote:
> Chris Marusich <cmmarusich <at> 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 <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#47698; Package
guix.
(Tue, 08 Jun 2021 08:24:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 47698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
LGTM!
--
Efraim Flashner <efraim <at> 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
[signature.asc (application/pgp-signature, inline)]
Reply sent
to
Chris Marusich <cmmarusich <at> gmail.com>:
You have taken responsibility.
(Fri, 18 Jun 2021 18:10:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Chris Marusich <cmmarusich <at> gmail.com>:
bug acknowledged by developer.
(Fri, 18 Jun 2021 18:10:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 47698-close <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Committed to core-updates in bcdc13454c4afab37b650d4bbfa95e539060619f.
--
Chris
[signature.asc (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 17 Jul 2021 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 294 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.