Bug 1798908

Summary: Broken xxhsum binaries created on ppc64le with gcc 10
Product: [Fedora] Fedora Reporter: Mattias Ellert <mattias.ellert>
Component: xxhashAssignee: Mattias Ellert <mattias.ellert>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: aoliva, avi.kivity, dmalcolm, fweimer, hannsj_uhl, jakub, jwakely, law, mattias.ellert, mpolacek, msebor, nickc, releng
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: xxhash-0.7.2-3.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-07 08:13:01 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, 1750908, 1792464    

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:

https://koschei.fedoraproject.org/package/xxhash?collection=f32

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:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1455002
https://koji.fedoraproject.org/koji/taskinfo?taskID=41323118

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):

gcc-10.0.1-0.3.fc32
gcc-10.0.1-0.4.fc32
gcc-10.0.1-0.5.fc32
gcc-10.0.1-0.6.fc32
gcc-10.0.1-0.7.fc32

How reproducible:

Always

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
 #else
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. ***