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 1798908 - Broken xxhsum binaries created on ppc64le with gcc 10
Summary: Broken xxhsum binaries created on ppc64le with gcc 10
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xxhash
Version: rawhide
Hardware: ppc64le
OS: Linux
high
high
Target Milestone: ---
Assignee: Mattias Ellert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 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:
Environment:
Last Closed: 2020-02-07 08:13:01 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github Cyan4973 xxHash pull 297 0 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:

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. ***
Note You need to log in before you can comment on or make changes to this bug.