Description of problem:
After gcc was updated to version 10, the xxhash package started failing to build on aarch64 and ppc64le. See the koschei history of the package:
The failure on aarch64 has since been fixed (see bug 1793471).
But the failure on ppc64le remains, and the package failed the Fedora 32 mass rebuild - on this architecture only. All others were successful:
In the build the compilation succeeds, but it creates a binary that when run gives the wrong result. The package build fails because the tests run in the %check fail.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Rebuild the xxhash package in Fedora Rawide for ppc64le.
Package build fails due to failing tests on ppc64le.
Package build succeeds on the other architectures.
Successful package build on all architectures.
This is a regression w.r.t. gcc 9.
This fails even at -O0 and fails even if the xx*.c files are preprocessed with gcc 10 and compiled with two years old gcc.
Just a wild guess, gcc 10 now supports __has_builtin macro, and it is used for some __builtin_altivec_vmul* hacks the source is doing.
The sources talk about something clang specific and then use the __has_builtin macro which now in GCC 10 will be 1 because
there is such a builtin in gcc for several years.
The following makes the test pass:
--- xxh3.h.jj 2019-10-08 15:11:56.000000000 +0200
+++ xxh3.h 2020-02-06 17:52:54.209759369 +0100
@@ -219,7 +219,7 @@ XXH_FORCE_INLINE U64x2 XXH_vec_revb(U64x
* Additionally, the intrinsic wasn't added until GCC 8, despite existing for a while.
* Clang has an easy way to control this, we can just use the builtin which doesn't swap.
* GCC needs inline assembly. */
+#if defined(__clang__) && __has_builtin(__builtin_altivec_vmuleuw)
# define XXH_vec_mulo __builtin_altivec_vmulouw
# define XXH_vec_mule __builtin_altivec_vmuleuw
Proposed fix forwarded upstream.
New build with the proposed fix applied: xxhash-0.7.2-3.fc32
*** Bug 1800284 has been marked as a duplicate of this bug. ***