Bug 1798908 - Broken xxhsum binaries created on ppc64le with gcc 10
Summary: Broken xxhsum binaries created on ppc64le with gcc 10
Alias: None
Product: Fedora
Classification: Fedora
Component: xxhash
Version: rawhide
Hardware: ppc64le
OS: Linux
Target Milestone: ---
Assignee: Mattias Ellert
QA Contact: Fedora Extras Quality Assurance
: 1800284 (view as bug list)
Depends On:
Blocks: PPCTracker F32FTBFS GCC10
TreeView+ depends on / blocked
Reported: 2020-02-06 09:43 UTC by Mattias Ellert
Modified: 2020-02-07 08:17 UTC (History)
13 users (show)

Fixed In Version: xxhash-0.7.2-3.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-02-07 08:13:01 UTC
Type: Bug

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github Cyan4973 xxHash pull 297 None open gcc10 altivec 2020-02-07 08:13:01 UTC

Description Mattias Ellert 2020-02-06 09:43:09 UTC
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):


How reproducible:


Steps to Reproduce:
1. Rebuild the xxhash package in Fedora Rawide for ppc64le.

Actual results:

Package build fails due to failing tests on ppc64le.
Package build succeeds on the other architectures.

Expected results:

Successful package build on all architectures.

Additional info:

This is a regression w.r.t. gcc 9.

Comment 1 Jakub Jelinek 2020-02-06 16:57:52 UTC
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 __has_builtin(__builtin_altivec_vmuleuw)
+#if defined(__clang__) && __has_builtin(__builtin_altivec_vmuleuw)
 #  define XXH_vec_mulo __builtin_altivec_vmulouw
 #  define XXH_vec_mule __builtin_altivec_vmuleuw

Comment 2 Mattias Ellert 2020-02-07 08:13:01 UTC
Proposed fix forwarded upstream.

New build with the proposed fix applied: xxhash-0.7.2-3.fc32

Comment 3 Mattias Ellert 2020-02-07 08:15:26 UTC
*** Bug 1800284 has been marked as a duplicate of this bug. ***

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