Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1294016
Summary: | findutils tests fail on PPC | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> |
Component: | findutils | Assignee: | Kamil Dudka <kdudka> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | jcapik, kdudka, msebor, normand, pbrobinson |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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 13:25:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1071880 |
Description
Peter Robinson
2015-12-24 04:31:30 UTC
Please re-check with findutils-4.5.16-1.fc24. Thanks for checking! I will have a look at that... 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. (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. 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. (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 I just tried to build f23 and f24 sources on f22 and got the same results. f22 sources work. Sry ... the failures were different in my case FAIL: test-mbrtowc1.sh FAIL: test-mbrtowc2.sh FAIL: test-mbrtowc3.sh FAIL: test-mbrtowc4.sh (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 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. 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. 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. 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... 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. reported upstream: https://lists.gnu.org/archive/html/bug-gnulib/2016-01/msg00011.html |