Bug 1294016 - findutils tests fail on PPC
findutils tests fail on PPC
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: findutils (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
:
Depends On:
Blocks: PPCTracker
  Show dependency treegraph
 
Reported: 2015-12-23 23:31 EST by Peter Robinson
Modified: 2016-03-06 00:33 EST (History)
5 users (show)

See Also:
Fixed In Version: findutils-4.6.0-2.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-06 08:25:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2015-12-23 23:31:30 EST
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3017350

FAIL: test-isinf
../build-aux/test-driver: line 107:  6027 Aborted                 (core dumped) "$@" > $log_file 2>&1
Comment 1 Kamil Dudka 2015-12-25 06:51:00 EST
Please re-check with findutils-4.5.16-1.fc24.
Comment 2 Peter Robinson 2015-12-26 21:32:35 EST
Still fails http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3022223
Comment 3 Kamil Dudka 2015-12-27 12:47:10 EST
Thanks for checking!  I will have a look at that...
Comment 4 Kamil Dudka 2015-12-29 17:24:14 EST
The failure is not introduced by a change in findutils.  Any findutils package that contains the failing test-cases fails in rawhide but succeeds in f23 build root.
Comment 5 Peter Robinson 2015-12-30 19:06:23 EST
(In reply to Kamil Dudka from comment #4)
> The failure is not introduced by a change in findutils.  Any findutils
> package that contains the failing test-cases fails in rawhide but succeeds
> in f23 build root.

That doesn't mean it's not an issue with findutils though. While it could be a change elsewhere (versions of dependencies, compiler flags, compilers etc) it could be a change that is expected that needs to be fixed or addressed in the findutils tests because they could be failing under the expected changes, or they could have been passing in previous releases due to a bug which is now fixed that uncovers the issue.

Fobbing it off with a "it works elsewhere" isn't a fix to the problem, and while it could be another components problem as the maintainer of findutils you need to investigate why so it can be reassigned to an explicit component.
Comment 6 Kamil Dudka 2015-12-31 03:57:16 EST
Sure.  Could you please give me SSH access to a machine where it fails?

I tried a RHEL-7.1/ppc64le box but the test did not fail as it did in rawhide.
Comment 7 Peter Robinson 2016-01-04 06:20:21 EST
(In reply to Kamil Dudka from comment #6)
> Sure.  Could you please give me SSH access to a machine where it fails?

You should be able to provision one in beaker.

> I tried a RHEL-7.1/ppc64le box but the test did not fail as it did in
> rawhide.

you should be able to do a mock build with a rawhide config on that and recreate the issue in mock
Comment 8 Jaromír Cápík 2016-01-04 08:21:45 EST
I just tried to build f23 and f24 sources on f22 and got the same results. f22 sources work.
Comment 9 Jaromír Cápík 2016-01-04 08:23:48 EST
Sry ... the failures were different in my case

FAIL: test-mbrtowc1.sh
FAIL: test-mbrtowc2.sh
FAIL: test-mbrtowc3.sh
FAIL: test-mbrtowc4.sh
Comment 10 Kamil Dudka 2016-01-04 08:39:16 EST
(In reply to Jaromír Cápík from comment #9)
> Sry ... the failures were different in my case
> 
> FAIL: test-mbrtowc1.sh
> FAIL: test-mbrtowc2.sh
> FAIL: test-mbrtowc3.sh
> FAIL: test-mbrtowc4.sh

These ^^^ will be fixed by the following upstream commit:

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=1f636508
Comment 11 Kamil Dudka 2016-01-04 11:45:18 EST
On rawhide/ppc64le it fails with:
test-isinf.c:149: assertion '!isinf (LDBL_MAX)' failed

A test-isinf binary built on rawhide fails everywhere.  A test-isinf binary built on f23 does NOT fail on rawhide.  Compiler/linker flags are the same in both cases.  What differs is the version of gcc: gcc-5.3.1-2.fc24.ppc64le vs. gcc-5.1.1-4.fc23.ppc64le.
Comment 12 Kamil Dudka 2016-01-04 11:55:47 EST
Additionally, if I preprocess test-isinf.c on f23 and then compile on rawhide, it does NOT fail.  The only significant difference between the preprocessed source code appears to be the use of __builtin_isinf_sign() by rawhide gcc.
Comment 13 Kamil Dudka 2016-01-04 12:21:45 EST
Looking more at the preprocessed source code, I see that f23 switches among __isinff(), __isinf(), and __isinfl() based on sizeof() of the operand given to isinf() whereas rawhide unconditionally uses __builtin_isinf_sign(), which is documented as type-generic:

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

If I preprocess the code with -D__SUPPORT_SNAN__ (which is also implied by -fsignaling-nans), the test succeeds on rawhide, too.
Comment 14 Kamil Dudka 2016-01-04 12:35:42 EST
Based on the above analysis, I tried the following patch:

--- a/findutils.spec
+++ b/findutils.spec
@@ -58,2 +58,3 @@ autoreconf -fiv
 %build
+export CFLAGS="$RPM_OPT_FLAGS -D__SUPPORT_SNAN__"
 %configure

... and findutils were successfully built on both the ppc64 arches:

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3037931

I am not sure whether it is the correct way to fix it though...
Comment 15 Martin Sebor 2016-01-04 23:34:40 EST
The GLIBC definition of the isinf() macro was changed recently in response to bug 15367 (https://sourceware.org/bugzilla/show_bug.cgi?id=15367).  This change is in Fedora 24 rawhide.

The test is failing because the computation of gl_LDBL_MAX in float.c results in a bit pattern that matches GLIBC's interpretation of infinity on this target:

#if (defined _ARCH_PPC || defined _POWER) && (defined _AIX || defined __linux__\
) && (LDBL_MANT_DIG == 106) && defined __GNUC__
const union gl_long_double_union gl_LDBL_MAX =
  { { DBL_MAX, DBL_MAX / (double)134217728UL / (double)134217728UL } };

On powerpc64le, the result is represented like so:

    ff ff ff ff ff ff ef 7f >ff< ff ff ff ff ff 8f 7c

(which GLIBC's own printf interprets as infinity) while GLIBC's LDBL_MAX is represented as follows (which formatted using the %La string results in 0x1.fffffffffffff7ffffffffffff8p+1023):

    ff ff ff ff ff ff ef 7f >fe< ff ff ff ff ff 8f 7c

GCC's __LDBL_MAX__ has the same representation in 5.1, 5.3, and on recent trunk (6.0).

I don't know why findutils computes its own value of LDBL_MAX but the value of the LDBL_MAX macro (or GCC's __LDBL_MAX__) is interpreted correctly by GLIBC's isinf().

There has been a lot of churn in the IBM floating point support in GLIBC.  If you think the GLIBC isinf() macro is buggy please open a bug against GLIBC.  Similarly for GCC's or GLIBC's LDBL_MAX.
Comment 16 Kamil Dudka 2016-01-06 08:25:05 EST
reported upstream:

https://lists.gnu.org/archive/html/bug-gnulib/2016-01/msg00011.html

Note You need to log in before you can comment on or make changes to this bug.