Please re-check with findutils-4.5.16-1.fc24.

Still fails http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3022223

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